►
From YouTube: IETF101-DETNET-20180323-0930
Description
DETNET meeting session at IETF101
2018/03/23 0930
https://datatracker.ietf.org/meeting/101/proceedings/
B
B
B
B
C
C
Hey
hey
thank
thank
her
for
this.
She
really
kicked
off
the
debt
net
and
really
made
sure
we
stayed
with
I,
Triple,
E
and
I
have
on
this
slide.
I
mean
she
she
she's
much
more
beyond
the
debt
net.
She
has
been
the
go-to
person
for
ietf
for
anything
on
entrepot
a
most
poor.
She
helped
kicked
off
the
coordination
group
in
2012,
which
has
made
a
huge
difference
in
the
relationship
we
just
had
the
meeting
this
morning.
C
We
meet
once
a
week
even
here
at
ITF,
and
it
really
makes
the
things
go
smoothly
and-
and
it's
really
of
course,
the
people
involved
and
Pat's
one
of
those
people
anyway,
we
think
50
was
her
first
IETF,
probably
it
could
have
been
earlier
and
in
802
they
had
a
big.
Thank
thank
you
to
her
because
she
is
known
to
have
been
the
one
to
have
she's
chaired
and
held
leadership
positions,
the
most
of
anybody
at
most
varieties.
C
A
B
Thank
you
so
much
so
here
is
our
note.
Well,
it's
the
end
of
the
week.
Everyone
should
be
familiar
with
it,
even
though
it's
a
new
form,
if
you're
not.
Please
take
a
look
at
the
link
on
the
bottom
and
read
about
it,
so
we
are
doing
audio
and
video
streaming
we're
also
doing
our
joint
minute,
taking
through
etherpad
I,
just
sent
the
link
to
the
list.
So
if
you
want
something
easy
to
click
on
just
click
there,
it's
also.
B
B
The
the
etherpad
link
I
want
emphasize
is
very
helpful
to
make
sure
that
we
capture
the
discussions
that
go
on
the
presentations,
the
what
we
have
slides.
We
don't
need
to
worry
about
that,
but
the
discussions
are
pretty
important
to
capture,
particularly
in
this
one,
we're
expecting
a
lot
of
discussion
in
the
second
half.
If
you
make
a
comment
at
the
mic,
just
jump
on
etherpad
and
make
sure
that
the
comment
was
appropriately
captured
so
that
it's
reflected
in
the
minutes
route,
that
would
be
very
helpful.
B
B
Int,
by
the
way
we
will
have
to
remote
presentations.
Our
second
session
is
a
little
different.
We
are
going
to
have
a
real
working
meeting
and
we're
going
to
try
to
confirm
some
of
the
discussions
that
have
happened
in
interims
in
that
since
the
last
meeting,
we
have
had
three
of
them
and
also
highlight
issues
that
are
still
open,
and
we
would
really
like
to
try
to
close
on
what
we
think
the
the
direction
is
that
the
working
group,
and
as
always,
we
don't
do
final
confirmation
of
decisions
in
here.
B
We
do
it
on
the
list.
So
the
discussion
follows
on
to
three
in
terms
that
took
place
it
will,
we
will
have.
Hopefully
a
good
discussion,
make
some
progress,
hear
the
results
of
that
progress
will
be
captured
in
a
document
and
then
that
document
will
have
an
opportunity
for
everyone
to
review
and
comment
on
list.
So
that'll
be
the
focus
of
the
second
session,
the
we're
going
to
adjust
the
timing
a
little
bit
partially
to
allow
for
a.
B
For
Stuart
Bryant
to
talk
a
little
bit
about
his
enhanced
VPN
framework,
which
we
expect
to
show
up
at
ease
but
is
actually
answers.
One
of
the
questions
we
have
on
our
slides
is:
how
do
we
that
we
need
it?
We
need
some
text
covering
our
the
the
VPN
behavior.
We've
always
talked
about
about
carrying
TSN
no
for
debt
net
and
that's
going
to
provide
a
higher-level
framework
of
it.
B
As
always,
we
really
like
discussion
on
the
mail
list
and
we
have
an
IPR
disclosure
process
where,
basically,
before
adoption
and
before
working
group
last
call
that
we,
we
asked
all
authors
and
contributors
named
in
a
document
to
explicitly
state
whether
they
know
of
IPR.
This
is
also
the
time
if
you're
working
in
the
working
group-
and
you
know
of
IPR
that
and
you
can
look
at
the
definition
and
then
oh
well
what
that
means
know
about.
They
are,
if
you
know
of
it,
that's
the
time
to
disclose
it
if
you
haven't
done
so
before.
B
So,
where
are
we
in
our
documents?
We
have
three
documents
that
we
keep
saying
we're
good
at
last
call
and
this
time
we're
not
kidding.
We
really
want
to
last
call
these
three
documents.
We
thought
we
were
going
to
be
into
last
call
on
two
of
these:
the
architecture
in
the
use
cases,
but
each
time
we
went
to
do
just
to
really
start.
The
last
call
the
author
said
that
we
have
one
more
thing
to
do
and
in
the
case
of
the
the
architecture
document
we
we're
there
now.
B
In
fact,
it's
not
on
the
on
the
agenda.
For
that
reason,
we
think
it's
done.
I
did
talk
to
Pascal
who's,
not
in
the
room,
but
is
a
co-author,
and
he
says
he
thinks
everything's
incorporated
if
it's
not
you'll,
send
it
to
the
list.
So
hopefully
we
won't
have
anything,
but
even
if
he
does,
we
can
capture
that.
As
a
last
call
comment.
Use
cases
will
here
shortly.
B
B
We
spent
time
on
it,
so
it's
good
to
capture
it.
But
if
the
text
is
a
little
too
dated
now
and
it
causes
us
a
lot
of
problems,
we
may
bring
it
back
to
the
working
group
and
say:
do
we
really
want
to
spend
focus
our
energies
there?
Perhaps
it's
better
to
focus
somewhere
else,
so
we'll
see
how
that
one
goes
on
the
agenda.
We
have
three
of
our
working
group
documents
that
are
not
yet
ready
for
last
call.
The
security
document
Ethan
will
give
an
update
on
that.
B
In
terms
of
our
deliverables,
welcome
Ethan,
that's
good
bodies
there,
so
in
terms
of
our
deliverables
and
milestone,
we're
actually
moving
along
slower
than
we
had
initially
hoped,
but
we're
still
we're
moving
along
on
three
of
the
four
in
terms
of
what
we
have
is
adopted
working
group
documents,
we
don't
have
any
yang
documents
or
yang
models
as
working
group
documents
yet,
but
we
do
have
an
individual
draft
on
it.
That's
on
the
agenda
that
we'll
be
talking
about
today
and
with
that
I
think
I've
gone
through
the
list.
Oh.
D
E
A
A
Schedules
and
ITF
is
first
it's.
The
third
starts
on
the
3rd
of
November
and
then
I
Triple,
E
802
starts
the
next
Monday
on
the
ninth,
so
I
I,
think
or
Sunday
on
the
night.
I
think
it
might
be
that
at
one
time
they
were
the
other
way
around
or
something
because
a
couple
of
people
have
thought
they
were
in
the
other
order.
But
but
I
checked
online
this
morning
and
it's
definitely
ITF
first
and
I
Triple
E
802
the
second
week
go
ahead.
F
Right
now,
the
I
Triple
E
802
that
one
has
a
joint
effort
going
on
with
ie
CSC
65,
which
is
on
industrial,
a
profile
for
time-sensitive
networking
for
industrial
uses.
If
we
can
get
them
to
come,
that
would
be
a
third
group
that
would
be
I,
think
it'd
be
really
valuable
for
them
to
see.
What's
going
on
in
debt
met
because
I
think
that
will
be
relevant
to
them
as
they
get
into
larger
networks.
Also
I'll
be
pushing
to
that
right.
A
G
Okay,
yeah,
you
sound
great
okay,
so
I'm,
you
think
grouse
go
be
laboratories,
and
this
is
the
update
on
the
debt
net,
use
cases
draft
and
next
slide.
Please,
the
current
status
is
that
we
did
put
together
a
use
cases
draft
14,
but
it
has
only
very
minor
changes
from
the
last
one,
the
main
one
being
that
we
moved
all
of
the
authors
which
all
used
to
be
on
the
front
page
to
a
contributor
section,
because,
as
you
know,
can't
have
them
all
on
the
front.
G
So
that's
what
we
decided
to
do
fixed
a
few
typos,
basically
the
same
as
it
was.
We
consider
the
draft
to
be
basically
stable,
ready
for
working
group.
Last
call.
There
was
a
couple
of
things
that
we
decided.
We
would
defer
till
the
last
call
process
instead
of
trying
to
get
him
into
draft
14.
One
is
that
there
are
some
texts
related
to
network
slicing,
that
we've
been
working
on
we'd
like
to
get
that
in
there.
But
it's
it's
just
a
more
clarification.
G
It's
good
stuff
and
I
sort
of
wanted
to
bring
up
the
topic
of
whether
we
should
say
something
in
the
youth
cases
draft
about
ipv4,
because
we've
got
a
lot
of
conversation
about
it.
Generally
speaking
in
the
UK
draft,
we
don't
attempt
to
suggest
any
kind
of
technology
or
solution,
but
on
the
other
hand
there
was
this
sort
of
moment
when
we
realized
that
for
a
lot
of
the
use
cases
it,
it
was
important
to
have
at
least
a
solution
for
ipv4.
G
Even
if
it
wasn't
the
complete,
more
complete
solution
you
could
get
with
with
ipv6.
For
example,
I.
Don't
know
that
I
want
to
actually
have
that
discussion
now,
because
this
is
a
very
short
update,
but
I
just
wanted
to
put
it
out
there
that
that's
another
thing
that
we
maybe
should
consider
on
the
list
or
if
somebody
already
knows
the
answer,
then
it
can
just
be
done
with
that
so
I
put
on
it.
G
So
that's
the
end
of
the
update,
we're
ready
for
last
call
and
and
that's
it
so
I
did
put
in
a
couple
more
slides
if
anybody
is
interested
in
reviewing
stuff
about
the
use
case.
Just
briefly,
one
of
the
things
was
the
notion
of
the
use
case,
common
cleans
in
the
only
reason
I
mention
it,
because
we've
gone
over
it
enough
times
is
because
it
does
get
referred
back
to
in
the
security
draft
update
which
I'm
going
to
go
over
next.
B
G
Okay,
so
just
I
mean
the
goals
we
provide
the
industry
context
for
debt
net,
a
yardstick
for
functionality
of
any
proposed
design,
and
we
highlight
the
commonalities
between
the
use
cases.
So
that's
that's
kind
of
what
I'm
getting
at
about
these
common
themes,
and
so
next
slide.
Please,
okay,
so
we're
gonna
go
so
future
plans,
even
though
we're
gonna
have
last
call
we're
still
going
to
use
the
use
cases
draft
as
a
yardstick
to
consider
the
value
of
the
proposed
solutions.
Next
slide,
please,
before.
B
G
B
You
have
the
text
ready
to
go.
I
think
it
would
be
much
more
efficient
for
the
working
group.
If
you
do
an
update
and
then
we
issued
last
call-
and
everyone
has
an
opportunity
to
review
that
new
text
does,
that
is
that
work
for
you?
How
long
do
you
think
you
need
for
to
get
the
next
Rev
out
with
that
text
that
you
have
in
mind.
G
B
I
think
it
would
be
much
better
to
hold
off
last
call
until
that's
ready
and
then
because,
if
as
soon
as
we
do
last
call
we're
asking
a
lot
of
people
to
look
at
the
document
and
if
you
then
add
new
text
that
it
means
they
have
to
look
at
it
again
and
it's
less
likely
to
get
as
good
review.
Then.
Okay.
B
H
B
That
we
should
start
with
the
cleanest
ten
yeah
I.
Think
I
heard
what
Stuart's
saying
it's
a
good
point.
It's
not
that
the
last
call
comment.
The
last
call
version
is
the
final
one
we
may
have
updates
based
on
last
call
comments,
but
if
the
author's
know
that
there's
texts
that
have
to
go
in,
we
shouldn't
start
last
call
to
that
text.
Is
there
either?
Does
that
make
sense?
Yeah.
G
G
B
G
All
right
we
can
proceed.
Okay,
so
I
was
just
going
to.
There
are
two
of
these
slides
on
that
show.
The
common
themes
and
I
was
just
gonna,
show
him
again,
because
when
I
talk
about
the
security
draft,
I
refer
back
to
these,
so
I
just
thought.
Instead
of
having
to
go
back
from
there,
we
go
forward
from
here.
So
the
point
is
that
these
are
like
the
least
common
denominators
of
all
of
the
different
use
cases,
because
the
use
cases
are
many
and
they're
complicated.
G
We
decided
that
it
was
good
to
identify
the
common
elements
of
them.
So
we
refer
to
these
as
the
use
case,
common
themes,
and
they
have
things
like
it
has
to
be
scalable
in
size.
It
has
to
have
high
availability,
it
has
to
be
secure.
The
flows
have
to
be
deterministic.
I
use.
This
deterministic
flow
is
isolated
from
each
other
that
one
I'm
going
to
mention
that
specific
common
theme
I'm
going
to
mention
in
the
security
update.
So
that's
the
only
reason
I'm
pointing
it
out.
Okay,
that's
it
for
that.
G
The
draft
is
considered
currently
to
adequately
cover
the
general
topic
of
security
for
debt
net,
that
is
to
say,
it
doesn't
yet
include
the
security
considerations
that
are
specific
to
whatever
data
playing
protocols
we
choose
to
use,
so
that
comprises.
What
we
have
to
do
next
is
to
add
the
security
considerations
that
are
specific
to
the
data
playing
protocols.
Once
those
decisions
are
made
note
that
the
scope
of
the
debt
net
security
draft
is
limited
to
security
considerations
that
are
specific
to
debt
net
ie
time
sensitive
things
that
we
we're
not
trying
to
cover
anything.
G
That's
covered
anywhere
else,
we're
just
trying
to
focus
on
these
specific
things.
So
that's
the
update,
I
thought
since
again,
since
it
was
a
short
enough
update,
I
did
prepare
two
very
brief,
slides
just
talking
a
little
bit
about
the
draft
and
what's
the
structure
of
it
and
part
of
it,
that
maybe
is
new
and
and
I
might
be
worth
a
word.
So
let
me
just
spend
a
minute
going
over
those
next
slide,
please
so
the
overview
of
the
draft
abundant
one
minute
I
cover
security
threats,
for
example,
delay,
spoofing
and
so
on.
G
The
impact
of
those
threats
you
know
is
that
a
financial
impact,
health
and
safety
impact
mitigations.
In
other
words,
what
do
you
do
about
those
threats
and
the
association
of
attacks
to
use
case
common
themes?
So
in
that
this
way
we're
trying
to
narrow
down
the
problems
of
securing
a
debt
net
based
on
knowledge
or
the
specific
application
or
use
case
it's
hard,
because
there's
so
many
use
cases
so,
instead
of
by
use
case,
we
organize
it
by
use
case
common
theme
as
I
was
just
discussing.
G
G
This
is
an
example
of
that,
for
example,
the
deterministic
flows,
one
that
we
just
discussed
this.
For
example,
the
third
paragraph
here
says
a
flow
modification
or
spoofing
or
header
modification
or
control
packet
modification
act
attack
could
cause
packets
from
one
flow
to
be
directed
to
another
flow,
thus
breaching
isolation
between
the
flows.
So
this
is
this
is
bringing
together
the
properties
of
a
debt
net
with
what
the
effect
of
a
successful
attack
could
could
could
do
to
that
particular
property.
B
J
So
this
draft
was
adopted
by
the
very
group
recently
at
the
last
after
the
last
meeting
and
what
we
have
discussed
there
is
that
this
draft
will
contain
not
only
the
flow
information
model
but
also
service
information,
other
specific
aspects
and
practically
this
is
that
we
have
updated
in
the
draft.
So
this
is
about
a
VSO
very
shortly
in
the
slides.
J
Regarding
the
service
information
model,
we
have
identified
only
the
basics.
Many
things
will
depend
on
law
also
on
the
result
of
the
data
plan
discussion
so,
but
we
have
put
in
the
draft
in
a
conversion,
is
ingress
related
information
element,
egress
related
information
element
that
not
domain
and
service
day
to
a
specific
information
element,
and
we
have
was
a
distinguished
two
type
of
service
over
the
dotnet
domain.
One
is
a
layer,
2
or
TSM
connectivity
service,
but
flow
contain
Ethernet
frames,
and
this
is
what
we
are
transporting
over
the
data
domain.
J
The
basics
of
service
attributes
were
also
listed.
It
is
the
bandwidth
parameters,
delay,
parameters,
loss
parameters,
I
think
nothing
surprising.
The
connectivity
type,
which
is
selected.
What
type
of
service
connectivity
is
provided,
a
layer
2
or
a
layer,
3
connectivity
in
order
delivery
and
the
service
rank.
J
We
have
added
also
based
on
the
architecture
draft
some
reference
points.
This
is
there
in
the
text
in
order
to
have
some
better
further
discussion,
so
they
might
be
removed.
If
we
don't
need
these
reference
points
for
the
service
definition,
but
I
think
some
of
them
will
be
definitely
needed.
So
what
we
have
added
is
just
what
we
have
in
their
architecture:
draft
the
application
flow
endpoint,
the
Uni
interface
and
the
neural
interface.
J
Regarding
the
service
scenarios,
we
have
not
added
yet
the
interim
results,
the
two
service
scenarios,
the
internal
service
and
the
darkness
service.
This
is
what
is
referred
in
the
current
version
of
the
document
and
practically
that's
it.
The
plan
for
the
future
is
to
incorporate
the
conclusion
from
the
data
plan
discussion,
because
that
will
impart
the
attributes
and,
of
course,
contributions
are
welcome.
Thank
you.
L
I
told
us
Eckhart:
is
there
no
support
for
the
model
where
the
end
device
itself
also
performs
dead
net?
So,
for
example,
I'm
aware
of
a
lot
of
the
video
application
devices
that
are,
you
know,
performing
something
like
what
we
call
press
meaning
receiving.
Both
streams
aren't
able
to
merge
these
and
so
I
think
that
the
use
cases
are
maybe
not
explicitly
mentioning
these
details,
but
obviously
these
video
services
and
so
I'm
wondering
how
that
would
be
captured
in
that
architecture.
I.
B
B
L
The
Uni
looked
is
is
exactly
not
saying
that
the
the
user
interface
is
dead
net,
that
the
user,
that
the
host
is
dead,
not
capable
right.
So
it's
kind
of
just
consuming
the
edge
representation
of
the
dead
net
service,
which
is
not
the
same
as
as
the
full
data.
Just
specifically
I
think
a
breath,
yeah
I
think
that'd
be.
B
J
J
M
N
N
We
can
say
this
picture
shows
the
circle,
often
that
control
and
manage,
and
the
blue
box
shows
the
flow
and
service
data
model
is
covered
by
a
current
draft
which
is
just
introduced.
But
then
I'll
flow
information
model
and
our
work
then,
and
a
configuration
model
covers
the
red
box,
including
three
parts.
Topology
data
model
configuration
data
model
and
the
state
has
data
model.
N
We
have
network
topology
data
model,
and
now
we
have
te
data
model
and
in
the
t's
working
group
we
have
te
topology
data
model
and
then
that
data
mode
does
not
polish
it
in
the
model
is
the
augmentation
to
the
current
te
topology
data
model
and
including
two
parts
know
the
attribute
augmentation
and
the
link
annotation,
and
let's
do
some
a
detailed
introduction.
These
are
the
attributes
are
included
in
our
work
and
which
is
necessary
for
DES
net,
but
not
in
the
current
D.
N
Actually,
as
we
all
know,
there
are
some
queuing
algorithm,
defining
in
actual
ETS
or
tasking
group
such
as
time
of
are
shaping
credit
based,
shaping
and
secured
a
lot
of
the
of
them.
It's
not
in
the
scope
of
the
current
than
that.
But
perhaps
it
is
an
interesting
issue
to
consider
that,
whether
them
that
should
have
their
dedicated
queueing
management
algorithm
or
we
should
do
some-
should
have
some
new
queue,
management
of
rhythm
and
question.
E
N
Different
queue,
management
algorithm
has
corresponding
basic
parameters,
and
we
also
have
a
resource
reservation
base,
which
is
also
has
been
defined
in
the
maximum
thing:
imports
maximum
packet
size
and
maximum
data.
There's
not
a
classes.
Let
me
a
little
explain
about
what
is
standard
class,
especially,
we
should
have
a
tetanus
traffic
class
to
distinguish
10m
flows
from
mountain
air
flows,
and
the
question
is
whether
we
should
have
more
than
one
traffic
class
for
ten
that
to
distinguish
different
data
flows.
N
That
means
the
10m
flows
have
different
priority
and
the
different
process
in
the
device,
and
we
also
define
the
bandwidth
and
the
delay
metric
for
test,
not
in
the
delay
metric.
We
just
do
the
delay
classification
in
the
into
three
parts
link,
delay,
processing,
delay
and
output,
queuing
delay.
Link
delay
has
already
been
covered
by
the
counter
work
and
packet
processing.
Delay
describe
delay
from
the
packet
from
the
packet
goes
into
the
device
and
arrives
the
output
queue
and
the
queuing
delay
is
the
from
the
output
queue
and
outside
device.
So
we
think
this.
N
E
E
N
E
E
E
Is
not
interphase
residence
time
is
measured
by
ingress
egress
of
interfaces,
how
we
traverse
the
node,
so
it's
an
ordered
pair
and
order
it
characteristic
because
it's
directional
so
ingress
to
egress.
That's
more
useful
and
helpful
information,
and
we
have
this
already
included
in
SFC
document
and
preparing
some
document
and
more
general
use
of
residence
time
in
calculating
T
Greg.
B
Lee,
but
it's
derivative
of
the
information
model,
so
the
the
base
concept,
you're
saying
that
here
is
represented
wrong.
Please
please,
go
please
go
look
at.
Please
go
look
at
the
the
previous
document
that
was
presented
and
see
if
you
think
it's
right
there
and
if
it's
not
suggests
a
correction.
Okay
list.
Yes,.
N
Sorry
I
think
it's
very
important
to
mention
that
I
think
the
magic
of
tenets
is
it's
not
the
delays,
not
from
measurement
it's
from
the
calculation
by
the
particular
queueing
management
algorithm
it
used.
So
it's
not
matter
so
it
can.
We
calculated.
So
the
delay
is
deterministic,
that's
the
point,
and
that
is
different
from
other
other
mechanisms.
Other
working
group
work.
F
Norm
fin
we've
got
a
new
draft
and
I
encourage
it
to
participate,
perhaps
in
the
new
draft
on
founded
latency,
where,
where
we'll
get
into
the
network
calculus,
and
what?
How
do
you
compute
and
there
did,
there
are
different
ways
to
do
it
and
we'll
pick
one
that
works.
I
would
just
like
to
comment
on
the
more
more
than
one
that
net
class
of
service.
A
great
many
applications
will
not
need
that.
M
F
N
D
N
L
Us
what
what
is
the
benefit
of
you
know
having
I
mean
not
happen
so
Tim
to
me.
What
would
be
a
lot
more
logical,
like
we
do
in
many
other
working
groups
to
have
something
like
the
yang
model
be
normative
for
the
information
model,
if
it's,
whether
you
want
to
one
translation,
seems
like
rather
wise
just
getting
ourselves
into
the
additional
problem
of
you
know
creating
yet
another
round
of
box
mapping
information
model
to
the
young
model
right,
so
just
curious,
I.
E
E
N
We
should
go
back
to
the
first
picture:
it's
not
the
same
data
model
covered
in
by
these
two
traps.
We
can
see
the
flow
data
model
and
a
service
data
model
from
the
user
to
the
controller
that
is
covered
by
the
information
model
and
what
we
cares.
The
tenets
configuring
a
model
covers
different
parts,
just
like
the
salt
bond
and
the
what.
N
L
Just
I'm
just
talking
about
getting
the
you
know
human
translation
from
the
information
model
into
the
data
model
out
of
the
picture
to
reduce
the
places
where
we
can
create
bugs.
So
what
is
your
proposal?
Well,
I'm,
not
sure
if
it
would
work
very
correctly
right
in
terms
of
if
there
are
so
many
abstract
things
in
the
information
model
that
we
haven't
captured
in
yang,
then
we
have
a
problem
right,
but
if
everything
that
we
have
in
the
information
model
is
meant
to
be
captured
in
yang,
why
the
heck
is
that
not
the
equivalent?
L
O
E
So
again,
I
hope
that
I'm
not
contradicting
tutorials,
because
organizations
usually
do
one
thing:
either
information
model
or
data
model
because
from
information
model,
its
mechanical
operation
to
derive
data
model,
making
two
parts
of
the
same
issue
problem,
because
basically
we
are
talking
about
part
that
covers
lifecycle,
orchestration,
okay,
with
their
service
model,
using
two
different
ways
of
looking
different
players,
because
one
layer
is
information
model,
another
layer,
a
little
bit.
It's
like
a
server
to
it.
It's
a
data
model.
The
problem
is
how
we
guarantee
consistency
of
these
two
views.
Well,
do.
B
Intent
has
been,
or
the
discussion
has
been,
that
we
have
the
information
model
that
helps
us
understand.
What
needs
to
go
in
to
the
yang
model
and
the
yang
model
is
the
thing
that
actually
drives
the
implementations.
So
the
information
model
is
more
about
our
the
process
that
goes
in
here.
Well,
the
data
model
is
more
about
what
happens
with
implementation
and
I,
see
that's
a
controversial
statement.
I'm.
B
That's
our
III
amusing,
that's
true,
and
when
they,
when
they
formally
define
the
information
model,
using
tools
such
as
UML
we're
not
doing
that
we're
in
in
we're
documenting
it
in
text
form,
which
means
that
the
only
way
to
translate
from
the
narrative
to
the
actual
data
model
is
a
human
process
and
that's
the
way
we've
been
doing
it,
whether
that's
right
or
wrong.
We
can
certainly
debate
no.
B
E
That
there
is
I
believe
there
is
no
right
and
wrong.
I
just
might
suggest
that
maybe
we'll
need
to
rename
it
from
information
model
to
information
flow
or
something
else,
because
information
model
exactly
associated,
at
least
in
my
mind
and
I.
Think
that
in
mind
of
others
couple
others
here
with
UML
and
being
able
to
produce
data
model
as
derivative
right.
B
So
it's
certainly
in
the
ITT
context.
Information
models
are
done
in
UML.
There
have
been
other
information
models
done
in
the
ITF
which
are
narrative
and
form,
and
this
one
is
aligned
with
what
we've
done
in
the
ITF
before
it's
not
aligned
with
what
has
been
done
with
information
models
in
ITT,
but
you're.
Absolutely
right,
there's
different
approaches
when
we
give
some
chance
to
some
others
to
talk
this.
P
Is
an
extremely
just
one
thing
to
add
to
this
and
there's
an
RFC
34:44
which,
which
explains
exactly
basically
the
difference
of
the
relationship
between
the
information
model
and
the
data
model,
I.
Think
basically,
the
trunk
of
this.
We
could
clear
up
this
really
clear,
clear
up
some
of
the
confusion
but
I
think
we're
having
here.
M
J
One
more
addition
barrage.
Rather,
the
information
model
is
about
the
flow
and
the
yang
model
is
for
configuration
for
all
the
details
so
from
the
fall
flow
you
will
select
but
to
configure
in
the
normals,
and
it
is
not
at
all
mentioned
in
the
flow
information
model
or
the
configuration
related
details.
This
is
why
we
have
separated
the
to
document.
B
Yeah
we
should
be.
We
should
be
careful
about
what
flow
means,
because
we
can
look
at
it
as
just
a
the
specific
series
of
packets
or
we
can
look
at
it
in
the
broader
context
of
of
how
our
charter
reads
it,
where
it
talks
about
information
needed
for
flow
establishment
and
control,
and
that's
a
little
broader
than
just
looking
at
a
particular
flow,
because
it's
all
the
information
needed
for
flow
establishment,
I
control
right.
E
Again,
it
might
be
just
a
certain
perception
that
when
we
somebody
mentions,
we
are
developing
information
model.
I
automatically
think
that
that
could
be
a
derivative
that
could
be
a
source
to
produce
a
and
model,
and
it's
not
only
ITT
that
uses
this
approach
worth
creating
information
models,
some
other
SDOs
produce
information
model
and
then
out
of
there
mechanically
derive
game
data
models.
L
Yes,
sorry
for
bringing
this
up,
and
just
you
know,
the
original
goal
was
really
trying
to
ask:
is
there
something
we
can
do
to
simplify
our
life
right
so
not
to
have
more
discussions
that
are
not
ending
right?
So
just
if
there
are
pieces,
you
know
that
we
know
are
going
to
be
met
one
to
one
right.
Is
there
any
way
to
avoid
that?
We
have
to
always
continue
to
check
consistency,
because
that's
where
it
came
from
right,
you
said:
oh,
don't
talk
about
these
parameters
in
the
yang
model.
L
Go
back
to
the
information
model,
then
update
that
draft,
and
then
basically
you
can
come
back
to
the
yang
model
and
get
that
draft
updated
right,
so
I
mean
that
that
was
basically
is
their
way
for
simplifying
our
life
saying
you
know
this
is
basically
the
yang
expression
of
parts
of
the
information
model
or
something
to
avoid
the
duplication.
That's
all
yeah.
B
B
Often
you'll
see
it
a
reference
in
that
case
in
the
yang
model,
where
you
have
a
normative
reference
to
where
that
parameter
is
described,
and
the
problem
is,
is
that
being
new?
We
don't
have
somewhere
else
to
reference
so
either
it
has
to
be
in
the
same
document
or
it
has
to
be
in
a
new
document,
and
we
then
take
the
approach
we've
been
taking
is
to
have
them
separate.
We
could
certainly
combine
the
documents
if
that
makes
sense,
but
then
that
becomes
a
new
massive.
L
Document
again,
as
I
said,
right
I
mean
if
it's
not,
you
know,
really
saving
us
work
at
this
point
in
time.
Right
forget
about
it.
I
was
just
thinking
that
you
know
looking
at
these
consistency,
issues
trying
to
you
know
be
as
efficient
in
what
we're
defining
you
know
with
the
least
amount
of
work
yeah.
B
L
N
B
It's
I
think
it's
actually
a
good
point,
because
right
now
we
have
information
split
over
two
places
having
it
split
in
two
places.
Is
it
good
and
I
think
even
hopefully,
everyone
will
agree
that
we
really
want
to
capture
the
narratives
in
one
place
and
then
have
the
syntax
definition
and
in
one
place
as
well
right
now,
it's
a
little
bit
spread,
which
is
definitely
not
a
good
situation.
N
So
I
will
go
to
the
next
night
and
after
the
introduction
of
the
tenant
apology
attribute
and
to
the
debate
of
the
models,
we
will
go
to
some
introduction
to
the
10m
flow
configuration
data
model
and
there
are
some
different
No
types
which
has
already
been
mentioned
in
the
telnet
architecture
dropped
and
the
different
node
types
play
different
role:
internet
network,
including
ingress,
node,
replication,
no
transcendence,
elimination,
node
and
egress
node.
These
different
roles
also
can
be
mapped
to
the
people
below,
and
all
these
different
different
roles
can
be
characterized
to
threaten
net
architecture
layers.
N
So
here
we
are,
there
is
the
low
lowest
layer
of
the
architecture,
transient
node
configuration,
and
we
will
include
some
parameters,
including
flow
priority
flow
identification.
Key
management,
algorithm
configuration
and
explicit
wrote
which
is
needed
to
be
considered,
and
it
is
also
mentioned
by
doing
in
the
Middle
East
is.
There
is
a
very
interesting
draft
in
another
working
group.
It
is
about
the
queues
young
model
and
we
have
do
some
analysis.
N
The
cucm
model
is
consistent
for
Bayesian
models,
classifier
policy
action
and
the
target,
and
it
also
defines
IETF
tips
or
young
model
based
on
these
four
base.
Llamados
and
this
part
work
may
be-
can
also
be
used
in
our
transcended
configuration
young
model
because
we
can
do
augmentation
to
this
llamado
and
and
and
that
that's
not
features
into
it.
This
may
be
the
next
step.
Work
of
this
document,
and
we
also
here,
are
some
attributes
about
the
relay
node
configuration.
The
relay
node
has
main
two
functions:
replication
and
elimination.
N
First,
we
will
do
flow
identification
and
the
specifies
whether
the
flow
will
do
a
replication
or
elimination
if
it
does
replication
which
specifies
the
copy
numbers
all
the
redundant
numbers,
and
after
do
the
replication
and
elimination
we
should.
We
should
end
the
information
of
flow
and
notification
to
guide
the
packet
to
the
next
relay
or
edge.
Node.
Here
is
an
example.
Any
question:
yes,.
L
N
N
B
To
do
this
again,
you're,
making
a
comment
on
the
architecture
document
she's
just
she's,
just
presenting
what
is
in
the
architecture
document,
so
the
architecture
document
is
about
to
be
lost
called.
If
you
don't
like
anything,
something
it's
in
there
they'll
be,
please
don't
wait
for
the
last
call.
You
know,
read
it
and
send
comments.
The
list
not
thank.
N
The
as
label
as
the
identification,
so
in
this
really
note
the
flaw
added
acacia
is
the
incoming
Ashley
and
the
way
well
specifies
whether
the
packet
will
be
replicated
or
eliminated
or
both,
and
we
also
have
to
specifies
the
outgoing
as
label,
which
guides
the
package
to
the
next
relay
on
each
node,
and
we
also
have
to
specify
the
output
pot,
which
guide
the
package
to
different,
explained,
wrote.
And
if
we
have
already
done
this
kind
of
configuration,
what
will
happens
in
the
data
plan?
We
can
see
in
this
picture.
N
The
first
package
encapsulation,
the
lowest,
is
the
payload
and
we
have
the
tenant
control
world
and
the
100y
is
the
as
label
and
the
t
label
is
for
transmit
and
the
ingress.
The
encapsulation
is
like
this
and
in
the
relay
note
that
we
can
see
that
the
s
label
is
switched,
it
has
been
switched
to
201
and
which
and
do
the
packet
replication
and
the
kinda
packet
to
the
next.
N
The
relay
node
and
the
label
is
switched
again
to
301
and
the
packet
is
a
will
cost
go
to
the
egress,
and
then
we
will
do
some
configuration
in
the
edge
node
in
the
ingress
node
configuration.
It
should
include
flow
identification,
praxic,
sequencing
technique,
capsulation
travis
specification
and
perhaps
also
flow
aggregation,
because
the
flow
aggregation
solution
has
not
been
clearly
defined
in
the
data
plan,
so
it
is
open
to
discussion
and
in
the
eQuest
node
configuration
will
include
flow
identification
pack,
hillary
ordering
and
the
packet
decapsulation.
N
What
is
the
next?
Actually
because
there,
the
data
plan
solution
is
being
discussed,
and
perhaps
there
will
be
some
conclusion
today
in
the
afternoon,
and
so
and
also
we
are.
We
should
consider
the
cooperation
with
the
I
Triple
E
data
model
definition,
so
this
will
remain
just
the
beginning
of
the
work.
We
will
have
more
considerations
about
queuing,
algorithm
configurations
and
will
improve
the
replication
and
the
elimination
part
and
also
end
the
10's
status
data
model,
and
also
ask
for
more
contributions
and
the
comments.
Okay,
that's
all.
Thank
you.
Thank.
B
You
very
much
any
other
comments.
So,
as
we
know,
we
do
have
a
chartered
item
to
work
on
any
models.
It
sounds
like
we
have
a
little
bit
of
a
some
follow
up.
That
needs
to
be
done
to
make
sure
that
the
document
is
appropriately
aligned
with
with
the
other
documents.
One
one
suggestion
I
have
there
is.
Is
that
if
you
find
that
you're
just
repeating
text,
that's
in
another
document,
don't
repeat
it
just
point
to
the
other
document?
Yes,.
I
B
And
personally
this
is
my
as
a
personal
perspective.
As
working
group
chair
is
I.
Hope
you
do
it
quickly,
because
I'd
like
to
see
us
have
something
that
we
could
pull
the
working
group
on
before
the
next
meeting.
I'd
like
to
not
wait
to
the
next
meeting
to
do
an
adoption.
If
we
can
get
there
actually.
B
B
It's
an
okay
number.
We
could
definitely
use
some
more.
How
many
think
that,
after
the
update,
that's
been
discussed,
that
it
would
be
ready
to
pull
for
working
group
adoption
and
keep
in
mind
an
adoption?
Isn't
the
final
place?
It's
the
starting
point
so
about
the
same
number.
So
it
sounds
like
it's
a
good
plan
and
we
look
forward
to
seeing
the
update
and
and
others
please
feel,
free
to
to
review
it
and
send
comments
to
the
authors.
Okay,.
B
I
What
we
discussed
during
the
interims
and
what
the
accurate
are
in
the
rims,
and
also
the
input
from
some
couple
of
other
volunteers
who
contributed
take
so
basically
from
a
front
from
the
two
to
zero.
So
this
is,
after
the
interim
three
ballast
put
a
bunch
of
text
about
the
domain,
specific
consideration
and
the
draw
lines
picture
about
how
in
in
scoring
a
different.
I
Deployment
cases
for
the
routing
service
and
preaching
service,
and
so
on
and
auntie
em.
So
this
was
really
useful.
It
probably
should
clear
things
up
for
quite
a
few
people
and
then
I
also
added
the
preliminary
text
for
the
a
simplified
IP
service.
That
was
the
solution
that
we
came
up
with
and
I
create
a
after
the
interim
tree.
So
next
on.
I
Then
from
three
to
four,
so
this
was
a
minor
update
at
test,
because
we
also
create
that
that
the
native
ipv6
based
solution
that
that
was
drafted
into
the
draft,
it's
a
no-go
just
because
it's
an
ipv6,
only
solution
and
so
on,
and
there
was
a
push
for
four,
also
covering
ipv4.
So
I
took
this
text
and
references
to
ipv6
souls
in
a
way
and
put
some
more
text.
I
Previous
work
that
we
had
in
the
very
first
version
of
the
of
the
working
group
document
on
beta
plane,
where
we
had
this-
is
pseudo
wire
in
a
pseudo
wire
Congress
tree
at
the
mpls
piece,
and
we
also
had
the
IPP
SM
and,
and
there
we
had
the
kind
of.
If
you
want
to
transport
something
over
IP,
you
should
look
these
another,
so
it
had
the
solutions
that
we
had
in
mind
based
on
the
RFC
40:23
and
ends
7510,
so
after
the
so
bit
of
history.
I
So
just
that
the
we
kind
of
been
there
already
a
long
ago
where
we
are
heading
again.
So
there's
a
couple
of
presentation
bringing
this
up
IP
solution,
it
was
basically
in
the
first
cut
of
the
working
group
draft,
does
remove
based
on
the
occupant
ation
what
he
had
at
that
time
and
after
this
long
rule
VB
came
up
with.
I
B
The
only
it's
Lou
what
the
point
that
the
only
made
I
just
want
to
highlight,
because
that's
going
to
be
one
of
them.
The
important
topics
that
we
talked
about
this
afternoon
so
keep
it
in
mind
and
come
to
the
second
session.
I
know
that's
attractive
to
do
other
things
Friday
afternoon,
but
please
come
join
and
participate
in
that
discussion.
B
I
So
this
slide
just
highlight
the
the
TX
on
contribution
from
pelage
to
kind
of
spell
out
what
is
assumed
to
be
visible
in
a
text
already,
but
what
was
kind
of
hidden
and
and
and
these
things
show
up
the
routing
service
and
also
the
for
the
written
service
for
Ted
net
so
and
and
the
one
that
I
have
rounded
with
the
red
circle
on
the
right
left
right
bottom
corner
is
the
simplified
IP
solution.
So
it
assumes
that
the.
I
Explicit
routes,
and
so
when
they
are
provided
by
the
M
transmitted
layer
below
it,
has
certain
limitations
that
we
come
later
on
and
for
the
other
solution
saw
the
tunneling
and
the
IPPS
N
and
M
PS
PS,
and
there's
a
good
chance
that,
if
we
are
a
go,
continue
on
this
route
at
the
same
between
the
the
Etna
layer
and
the
end
system,
payload
the
same
actually
can
be
unified.
With
a
small.
I
So
I'm
just
reminding
the
constants
from
the
interim,
so
we
to
simplify
the
IP
data
plane
service,
the
identification,
because
we
don't
have
anything
that
we
could
insert
into
the
application
initiate.
It
originated
IP
packets,
so
we
basically
settle
down
with
a
sixth
up
or
so
that
the
typical
file,
support,
plus
DHCP
for
the
flow
identification
and
and
the
addition
of
DHCP
allows
you
actually
a
kind
of
distinguishing
between
different
TechNet
flaws
and
also
kind
of
also
builds
the
kind
of
basis
for
the
aggregation
of
definite
flows.
I
And,
as
I
said
earlier,
the
underlying
sub-link
sub
network
is
responsible
for
different
functions
and
the
Saudi
SEM
IP
packets
mess
on
to
each
hop
and
then
map
to
appropriate
the
dentate,
bullying
and
sub
network
for
the
next
hop,
and
so
on
so
browse
for
the
solutions.
It's
simple
and
doesn't
require
me
from
the
application
IP.
I
The
concepts
is
that
we
already
discussed
in
the
last
time,
and
what
is
this
figure
tries
to
explain
that
we
that
we
kind
of
lose
the
intent
properties
of
one
of
our
dear
child
or
discussion
points
of
the
elimination
and
packet
replication.
So
that
cannot
be
done
in
to
end
without
doing
that
at
the
upper
layers.
So
therefore
application
layer,
but
that's
out
of
scope
out
of
us.
So
what
actually
happens
that
you
still
have
this
this
service
protection,
but
that
is
on
each
network
segment.
I
So
that's
a
separate,
so
you
don't
have
the
end-to-end
Service
protection
at
the
data
layer
which
simplify
the
IP.
You
can
build
that
on
on
your
higher
layers,
if
you
want
yeah,
yes,
okay,
this
there's
a
more
neat
and
more
more
details
about
this
in
a
later
presentation,
especially
the
one
at
the
next
session.
Ok
next
slide
and
what
next
so
I
think
we're
in
a
part
that
we
can
split
the
document.
The
simply
got
IP
is
going
to
be
as
well
encapsulation,
pretty
simple
the
MPLS
based,
so
we
can
do
the
clear-cut.
I
I
So
there
is
still
kind
of
missing
things,
especially
on
the
kind
of
detailed
behavior
of
certain
knowns
and
the
kind
of
advanced
parts
of
the
behavior.
They
are
boring.
So
that's
why
they
haven't
been
progressed
and
then
something
that
that
be
properly
and
I
hope
that
we
discussed
today
and
make
a
decision
whether
the
impedance
based
solution
also
allow
IP,
PSN
or
just
MPLS
PA
in
Seoul
I.
Think
we
need
to
have
a
sort
of
agreement
on
this
part.
Also.
B
H
H
So
there's
some
there's
some
language
difference
between
the
description
used
in
the
solution
document
and
the
language
that
one
would
naturally
use
in
an
IP,
MPLS
context
and
indeed
the
language
that
the
operators
of
such
a
network
would
expect
he
to
say
so.
I
wanted
to
get
it
aligned.
This
is
a
possible
starting
point
for
an
MPLS
data,
plane
spec.
H
What
we
do
is
with
it
is
really
up
to
the
working
group,
so
I
think
it's
unlikely
that
in
the
MPLS
case,
we
will
have
anything
other
than
the
overlay
model.
I
know
of
no
example
where
MPLS
has
got
to
the
to
the
end
system,
and
so
I
wrote
it
really
as
a
multi
segment,
Suda
wire
design
would
look
and
the
the
the
picture
I
show
there
is
exactly.
H
H
One
of
the
things
that's
quite
interesting
is:
if
this
is
a
pure
in
that
net
system,
then
there
there
are
no.
There
are.
There
are
service
labels
visible
at
every
node
and
the
transport
labels
are
all
are
always
missing.
I,
don't
know
whether
that
will
lead
to
a
scaling
issue,
because
it
certainly
led
to
scaling
issues
when
people
tried
to
map
pseudo
wires
directly
to
LSPs,
and
so
the
scope
of
the
S
flavour
is
always
the
receiving
decnet.
Node
I.
H
H
H
Can
we
live
in
an
overlay
model
with
only
28
or
0,
and
if
it's
going
to
be
anything
other
than
28?
Is
this
a
parameter
of
the
wire
at
setup
time
or
is
it
a
parameter,
that's
carried
within
the
within
the
the
packet
in
the
philosophy
of
MPLS?
It
would
be
a
parameter
of
what
I've
been
calling
the
wire.
It
will
be
a
parameter
of
the
set
up
thing,
so
you
do
everything
in
signaling.
I
have
an
extremely
lightweight
data
plane
is
the
MPLS
philosophy
the
OEM?
H
There's
a
decision
that
we're
gonna
have
to
have
to
take
flow
aggregation,
so
I
put
two
models
of
flow
aggregation
in
there
because
again,
it's
not
clear
to
me
whether
we
want
to
aggregate
so
that
a
new
S
label
and
control
light
well,
so
a
new
control
label.
So
a
new
control
word
is
available
each
time
we
do
an
aggregation.
If
we
don't
do
make
the
control
word
available
ie,
we
split
the
stack
and
have
two
s
bits.
We
don't
do
that.
Then
we
can't
do
press
on
a
an
aggregated
segment
and
I.
H
P-Waves
right
so
in
pwe
3,
we
just
powers
we
just
used
to
who
wrap
everything
and
send
it
across
in
dead
net.
We're
going
to
have
to
have
some
sort
of
ACL
thing
and
we're
gonna
have
to
support
as
I
understand
it.
Three
types
of
packet
ethernet/ip
for
an
ipv6,
and
it
may
not
be
commonly
the
common
knowledge
here
that
MPLS
never
uses
the
IP
version
to
figure
out.
What
is
what
type
follows?
H
E
H
E
H
E
B
So
I
think
you.
Actually,
this
is
Lu
year,
I
think
you're
actually
you're
actually
both
correct
to
some
degree.
You
rely
on
a
combination
of
the
control
plane
and
typically
you
rely
on
the
control
plane
in.
There
is
a
case
where
the
control
plane
says
this
is
IP
in
which
you
go.
Look
at
the
first
nibble
get
to
figure
out
the
versions,
I
think
I
think
you're
both
actually
and.
E
H
B
H
E
H
H
We
need
to
see
how
that
applies
to
to
this.
Yes,
yes,
sorry
but
I
told
me
that
earlier
in
the
week
and
I
thought
about
it,
so
I
think
there's
a
few
things
we
need
to
do
here
right.
We
need
to
verify
that
detonate
that
we
as
a
working
group
consider
this
is
an
accurate
reflection
of
the
design.
H
B
You,
as
we
talked
about
earlier,
we're
gonna,
be
having
a
good
discussion
on
data
plane
in
the
second
session,
we'll
look
to
in
their
wrap-up
to
figure
out
next
steps.
Certainly,
as
yani
already
said
in
his
slides,
he
sees
there's
good
text.
There.
I
personally
see
there's
good
text
there,
we'll
figure
out
how
to
bring
them
all
together
into
a
working
group.
Yeah
give
you
guidance
from
the
chairs
as
to
how
we
move
this
blue
code
that
we
discuss
it
in
the
wrap-up
section
right
this
afternoon.
B
J
J
M
J
B
H
B
R
I'm,
just
making
sure
I
stay
in
the
pink
box:
okay,
I'm,
Andy,
malice,
my
co-authors,
are
Stewart
and
mock
and
pelage.
So
this
right
here
is
a
derivative
work
from
DP
Saul.
It's
also
a
a
a
derivative
work
from
Stewart's
draft
that
we
just
heard
from
so
we
use
the
same
terminology
in
the
same
abbreviations
and
so
on.
It's
basically
meant
to
augment
or
replace
the
text.
R
That's
currently
in
sections,
5,
dot,
2.27
and
8.7
of
D
piece
all
in
its
talks
about
the
encapsulation
for
debt
net
packets
when
carried
over
an
ip-based
debt
net
infrastructure,
and
it's
not
just
an
encapsulation
for
IP
over
debt
Annette.
All
of
that
certainly
one
of
the
multiple
use
cases
so
I
just
wanted
to
make
that
clear.
R
B
Gonna
actually
interrupt
for
a
moment,
because,
just
as
for
context
for
the
working
group,
this
is
documenting
something
that
was
presented,
I,
think
in
Prague
and
and
as
this
in
the
solution
document.
So
you
can
go
back
there
and
at
the
time
the
feedback
from
the
working
group
is.
We
didn't
want
to
go
this
direction
and
at
the
interims
we
were
struggling
with
this,
and
this
was
a
discarded
option,
and
so
it's
good
for
understanding
that
this
was
basically
ruled
out
in
Prague.
B
Stewart
made
the
point
that
this
this
approach
was
never
implemented
and
we
shouldn't
head
this
way
and
then
we
also
had
discussions.
We
also
had
discussions,
wait
one
sec,
you're,
free
to
correct
me
in
a
second.
More
importantly,
we
had
discussions
that
this
did
not
align
well
with
hosts
and
that
we
wouldn't
be
able
to
deliver
an
end-to-end
debt
net
service
with
this
approach,
and
that
is
what
led
us
towards
the
simplified
approach
and
in
the
interims.
B
R
And
also
just
to
to
to
talk
about
what
you
just
said,
this
is
this
is
actually
the
result
of
the
third
interim
and
I'll
be
going
to
that
a
bit
more
in
the
next
slide.
It's
basically
a
dis
got
a
result
of
the
discussion
in
the
interims,
especially
the
third
interim,
where
we
decided
on
the
simplified
model.
R
Also,
there
were
comments
in
the
third
internment,
perhaps
of
previous
interims,
that
debt
net
is
basically
for
at
least
some
of
the
use
cases
a
non-starter
if
you
can't
use
it
over
ipv4
over
an
ipv4
subnets
met
to
basically
allow
debt
net
to
be
used
in
the
use
cases
that
require
an
ipv4
subnet.
Don't.
R
I
do
that
on
the
slide
right
here
perfect.
Thank
you,
okay,
very
good.
So
basically,
this
is
based
on
the
simplified
model,
as
discussed
during
the
interim.
The
third
interim
on
on
the
14th
of
February.
Basically,
in
this
case
and
systems,
are
not
debt
net
aware.
So
that's
the
host.
There's
no
debt
net
header
in
the
host.
They
typically
sent
IP
packets
or
non
IP
application
frames
over
Ethernet
over
an
Ethernet
DSN
link
or
even
a
TSN
network
to
an
edge
node,
which
is
shown
as
the
next
node
over
next
to
the
end
system.
R
There,
which
then
adds
the
debt
net
encapsulation.
So
the
debt
net
capsulation
is
not
being
done
in
the
host,
and
this
is
based.
This
is
by
the
way,
the
exact
same
figure
that
Stuart
had
in
his
document
and
in
his
slides
I
just
changed
a
couple
of
the
labels,
because
it's
not
it's
not
using
an
MPLS
subnet,
it's
using
an
IP
subnet
other
than
that.
This
is
the
exact
same
figure
that
Stuart
had
in
his
document,
and
it's
based
on
the
figure
that
you
showed
low
in
the
third
interim.
R
Okay,
so
so
in
this
diagram,
edge,
nodes
and
relay
nodes
are
the
ones
that
are
getting
it
aware.
So
you
can
see
that
we
show
detonate
in
system
edge,
no
transit
node,
which
is
not
detonate,
aware.
A
really
note
in
each
node,
which
are
an
event
end
system,
which
is
not
aware,
and
the
edge
notes
is
very
similar,
as
Stuart
said,
to
PE
routers
for
pseudo
wires
or
MPLS
VPNs.
R
Okay,
any
questions
on
this
slide.
Okay,
so
what
we
want
to
do
is
we
want
to
take
advantage
of
work.
That's
already
been
done
in
DP
saw,
and
so
basically
the
transport
getting
it
over
IP.
You
require
a
couple
of
things.
You
require
a
method
to
identify
the
TechNet
flows
and
a
method
to
carry
the
dead
net
sequence
number
well.
Both
of
those
are
already
available
in
DP
saw
in
the
MPLS
encapsulation,
so
this
is
just
copied
directly
from
DP
saw
as
a
reminder
for
people.
This
is
the
net
MPLS
encapsulation,
that's
currently
in
deep.
R
In
DP
saw
the
control,
word
has
the
sequence
number
and
the
S
label
identifies
the
flow,
so
the
Iping
capsulation
is
very
simple
for
transport
over
IP
the
transport
labels
from
the
previous
slide
and
replaced
by
UDP
and
IP
as
specified
in
RFC
7510
for
a
carry
MPLS
over
UDP.
The
encapsulation
is
added
and
removed
in
the
edge
notes.
R
Ok,
some
notes
on
this
encapsulation.
First
of
all,
it
works
equally
well,
if
ipv4
and
ipv6
just
to
show
you
right
there
that
IP
header
down
the
bottom
that
could
be
either
v4
or
v6.
Everything
works
just
fine
either
way
it
works
with
MPLS
based
segment
routing
as
Pesa
fied
in
ITF
spring
segment,
routing
MPLS.
In
that
case
there,
the
t
label
that
you
see
in
that
picture
right
there
is
retained
in
the
each
segment
endpoint.
The
top
to
you
label
is
popped
and
mapped
to
a
corresponding
UDP
IP
tunnel.
R
H
Have
a
question:
I
do
a
terrifying
point,
which
is
the
assertion
that
this
encapsulation
string
can't
be
used
in
a
host
from
a
host
point
of
view.
The
UDP
piece
down
would
look
like
a
socket
call
and
the
piece
above
it
is
just
some
magic
numbers
in
the
in
the
host
payload.
So
I,
don't
honestly
see
why
we
can't
use
exactly
the
same
thing
from
a
host
as
well
as
from
an
edge.
So
the
discussion
was.
B
B
H
B
The
feeling
was
that
you
know
we
operate
on
consensus.
A
little
loose
was
that
that
wasn't
a
reasonable
ask
and
we
certain
if
we
did
that
we
certainly
would
have
to
coordinate
with
the
transport
area,
because
we're
now
mucking
with
basically
the
transport
interface
right
and-
and
that
was
viewed
as
too
complex.
Now.
The
approach
taken
here
to
me
sounds
like
it's
just
running,
taking
the
MPLS
solution
and
running
it
over
an
IP
PSN,
which
you
know
that
that's
just
I,
you
know
MPLS
over
IP.
B
We
know
how
to
write
how
we
just
need
to
make
sure
that
we
do
it
consistent
with
how
the
whole
industry
does
it
now
yeah,
you
know
sure.
That's
that
sounds
reasonable,
but
taking
it
to
the
host
was
where
there
was
a
lot
of
pushback
and
in
particular
we
wanted
to
make
sure
that
we
didn't
forget
about
v4,
hosts
and,
and
some
of
those
hosts
are-
and
this
is
I
think
something
that
came
out
of
Giles
presentation
was
this
or
maybe
some
side.
E
E
E
B
I'm
gonna
actually
yoni
was
in
queue,
okay
and
he
actually
was
in
queue
after
Stuart
I
apologize,
I
missed
him,
so
Stuart
I
think
this
is
in
response
to
you.
The
Oni
says
it
is
doable.
One
can
view
it
as
tunneling
stripping
the
additional
IP
header
away
was
the
hard
part
for
the
host.
That
was
his
view
of
the
host
okay.
I
H
L
Okay,
honest,
yes,
I
heard
something
here
about
inserting
the
setter
in
the
middle
and
to
the
best
of
my
knowledge.
If
the
host
you
know
generates
IP
packets,
then
I
don't
see
a
way
today
allowed
by
the
ITF
to
not
have
basically
two
IP
headers,
writes
your
IP
error
from
the
dead
net,
and
then
you
know
the
payload
packet
would
have
to
have
its
own
IP
header
right.
L
S
I'm
sure
who,
from
Alibaba
I
just
noticed
you
are
talking
about
how
to
use
MPs,
SRO
or
IP
in
completion
for
dotnet.
If
so,
I
suggest
you
to
order,
please
I
I
believe
this
format
is
almost
no
difference
from
the
MPs
are
a
YP
capsulation
right.
Yes,
that
difference
is
on
the
neck
controllers,
a
layer,
but
this
is
the
original
than
that
MPs
encapsulation
yep,
like
so
I,
suggest
to
and
a
reference
to
the
MPS
or
IP
dropped
in
this
in
your
document.
S
B
T
L
Okay,
so
I
don't
think
we
have
talked
much
about
multicast
forwarding
planes
and
you
know
it
could
as
well
talk
about
yeah
the
the
existing
multicast
forwarding
planes.
But
you
know,
given
how
that
net
is
a
future
architecture
that
we
want
to
build.
We
wanted
to
kind
of
show
what
we
think
is
the
you
know
the
best
forward,
going
multicast
forwarding
plan,
giving
traffic
engineering
and
everything
else
and
were
just
also
in
the
process
bringing
into
that
work.
The
elements
that
we
think
are
missing
for
that
net,
so
in
beer
with
traffic
engineering.
L
So
if
you
see
here,
there
is
this
red
path
with
the
bits
two
three
four
and
five
meant
to
deliver:
traffic
from
P
11
to
the
receivers,
P,
2
and
P
3,
and
that
would
effectively
result
in
a
beer
te
header
with
exactly
these
bits
set
being
sent
from
the
source
which
we
call
the
ingress,
VFR,
ear,
router
and
being
forwarded
along
that
path
to
work
and
replicated
to
what
these
receivers.
So
that's
a
really
a
very
simple
thing
and
these
bits
are
per
packets
or
at
that
level
we
don't
have
any
notion
of
flows.
L
So
you
know
the
sender
is
free
to
choose
that
on
every
packet.
Now,
when
we
look
into
what
we
think
is
missing
for
a
debt
net
in
the
in
the
forwarding,
that's
primarily
the
aspect
of
pref
or,
however,
we
call
it
now
and
so
in
this
example.
What
we're
showing
is
that
we
do
have
two
alternative
paths
right,
one
going
through
p1
on
going
through
the
other
part
of
p3
and
p4.
L
All
these
bits
being
said
and
the
elimination
function
itself
is
something
that,
as
we
said
in
the
architecture,
also
can
happen
in
the
middle
of
the
path.
So
you
know
these
bits
being
set.
The
elimination
function,
of
course,
for
its
operation
needs
to
have
a
context
which
I
you
know,
call
the
sequence
number
space
here
and
then
the
sequence
number
associated
with
the
packet.
How
we
construct
the
sequence
number
space
is
something
for
us
to
work
out.
L
As
you
know,
provision
for
the
dead
net
service
and
not
only
on
the
egress
you
can
also-
and
this
is
the
next
slide
by
the
way-
see
that
you
can
sustain
arbitrary
level
of
failures
depending
on
how
much
you
know
path
your
provision.
So
this
is
basically
the
example
where
you
have
two
consecutive
failures
on
different
paths
right,
but
you
would
still
support
it
because
the
elimination
function
helps
you
to
basically
overcome
this
amount
of
failure.
Yes,.
E
L
E
E
L
I
think
that's
exactly.
You
know
whether
we
want
to
reuse
the
existing
ether,
type
or
quality
v2
of
that
or
assign
a
different
ether
type,
so
I
think
that's
good
work
to
figure
out,
but
I
think
it
seems
to
be
clear
that
the
control
work
that
we
need
for
prep
is
a
similar
element
in
the
headers,
as
we
have
for
other
services
right,
they're
not
needed
for
the
actual
beer
forwarding,
but
for
the
overlay
service
that
we're
running
here,
and
that
would
be
the
dead
net
service.
L
So
that's
basically
the
resilience.
The
pressure
part
I,
think
you
know,
given
how
dead
net
you
know
targeted
for
layer,
3
environments
would
get
into
topologies
that
one
ready
one
minute
are
not
that
common
in
the
TSN
case,
so
I'll
skip
the
OEM
stuff.
This
is
basically
an
example
that
you
can
read
on
your
own
time,
given
how
I'm
shot
down
to
basically
show
the
efficiency
that
we
get
with
the
EF
in
you
know
typical
layer,
3
topologies,
like
rings,
and
that's
basically
exactly
the
considerations.
L
What
we
said
elimination
function
is
on
ingress
and
then
of
course,
the
whole.
You
know
traffic
engineering
architecture,
PCC
managing
the
vent
with
and
providing
calculation
of
the
past,
so
that
discussion
has
started
in
that
he's.
Working
group
yep
also
we're
looking
into
allowing
to
do
the
prep
in
beer
itself,
there's.
Basically
the
path
engineering
resilience
discussion,
because
we'll
have
to
rely
on
a
GPS
as
opposed
to
on
a
PC,
ECC
and
yep.
Those
are
the
references.
B
B
F
If
we
have
bounded
latency,
we
can
compute
how
many
buffers
we
need
to
get
zero
congestion
loss.
Any
scheme
that
regards
that
uses
feedback
to
slow
down
the
source
is
not
an
option.
We
have
fixed
band
where
we
have
minimum
bandwidth
required
for
each
flow
and
mathematically
sound
assurances
can
be
given
on
latency
and
congestion
loss.
We're
not
interested
in
probability.
So,
given
that
most
of
the
debt
network
we've
been
done
has
been
talking
about
packet,
replication
and
elimination,
because
that's
more
a
fun
topic,
everybody
has
an
opinion.
F
There's
lots
of
ways
to
do
it,
but
it's
not
a
trivial
problem,
so
that
makes
it
really
interesting
and
it's
very
similar
to
existing
uses
and
MPLS
is
a
familiar
technology.
So
everyone
has
an
opinion.
Okay!
Well,
this
isn't
the
only
thing
in
debt
net
founded
latency
is
the
most
important
feature
to
most
of
the
application.
F
Well,
the
unserved
technology
technologies
do
work.
Hardware
is
a
lot
cheaper
now
than
it
was
in
1995.
There
are
also
a
number
of
new
queuing
and
transmission
selection
techniques.
Besides
those
that
were
explored
in
it
serve
that
offer
different
trade-offs,
and
there
are
awful
lot
of
trade-offs
in
this
space
and
I'm
anxious
to
get
us
talking
about
them
between
low
latency,
latency
variation,
implementation,
collection,
complexity
and
the
complexity
of
what
you
have
to
do
to
make
a
reservation.
F
Ok,
there
are
all
different
places
in
those
Speight
in
that
four
dimensional
space
for
sweet
spots
for
solutions.
And
now,
if
you
remember
in
Singapore,
we
got
a
presentation
from
jean-yves
Lagoo
Dec,
which
was
very
exciting
because
he's
one
of
the
people
who
have
pretty
much
invented
Network
calculus
as
we
as
we
know
it,
and
we
believe
that
we
can
do
the
net
necessary
network
calculus
in
a
way
that
doesn't
require
a
PhD
to
do
a
thesis
for
each
flow
that
you
set
up.
F
F
It
has
an
introduction.
It
has
a
section
on
network
calculus,
which
will
be
greatly
expanded
in
the
next
two
or
three
weeks.
I
believe
we
have
a
section
on
what
it
takes
to
compute
the
necessary
buffers.
We
have
a
section
that
may
be
too
large
on
queuing
models
at
some
point.
We
need
to
a
map.
We
need
to
make
a
salon
to
make
a
selection
of
queuing
models,
or
at
least
going
forward.
F
Anyone
who
has
a
queueing
model
that
they
want
to
use
for
that
net
needs
to
be
able
to
map
their
queueing
model
to
the
requirements
to
the
parameters
that
we're
going
to
have
in
this
bounded.
Latency
document,
the
most
important
section
I
believe,
is
section
8,
which
is
how
to
character
Rhys
queuing
models
so
that
you
can
compute
the
latency
for
a
flow.
F
F
U
F
Is
a
somewhat
complex
problem?
The
expectation
is
that
a
given
application,
a
given
flow,
has
a
requirement
for
end-to-end
latency,
okay,
and
that
you
have
to
reserve
resources
in
the
network
for
that
latency
and
that
maybe
we
have
a
meant
to
control
plane
issues
at
the
very
least
using
the
yang
models
that
we're
developing
right
now
we
will
be
able
to
have
a
central
controller,
make
inquiries
of
the
network
and
be
able
to
construct
a
yes
or
no.
Can
we
meet
that
latency?
It
will
be.
F
U
U
U
B
Okay,
so
we
should
we
should
let
the
next
presenter
talk.
Okay,
if
we
have,
and
if
we
have
time
this
is
I,
don't
think
we
have
time
this
afternoon
to
get
into
it,
but
it's
an
important
discussion
that
would
be
great
to
take
to
the
list.
It
is
an
important
enough
discussion
that
if
we
want,
we
can
even
schedule
an
interim
just
on
this
one
topic.
What
once
we're
settled
out
on
the
caps
elations
norm?
Would
that
work
for
you
to
just
give
a
thumbs
up
all
right?
O
To
backgrounds
our
mark
cast
series
and
we
can
see
in
the
use
case
of
the
net
that
are
some
use
cases
around
mark
cast,
and
it
said
the
mark
has
capability:
I
should
have
be
integrated
into
the
to
the
net.
Another
thing
is
a
marketer
and
broadcast
is
a
a
key
enabler
for
the
5
T,
and
we
can
see
quite
a
few
use.
Cases
relied
on
the
market
share
capability.
O
O
Well,
sister
Bachmann
propose
another
solution,
so
we
can
use
another
technology
here,
as
you
can
see
how,
when
the
services
are
going
to
sell
from
the
routiers
and
it's
a
replicated
into
two
directions,
one
in
that
clockwise
and
another
in
the
context.
Otherwise-
and
then
I
each
node
around
the
union,
we
were
processed
advisor.
O
O
O
So,
as
we
can
see,
the
mark
asked
her
in
the
terrain.
It's
a
very
efficient
at
most,
only
two
copies
of
package
is
center
of
the
in
this
solution.
It's
also
a
very
comparable
with
Kitty
to
know
that
Annette,
as
you
can
see,
it's
almost
great
us
for
the
net
and
the
unicast
and
I
mean
mark
asked,
can
use
the
same
Magnussen
such
as
the
replication
and
the
elimination.