►
From YouTube: IETF106-DETNET-20191121-1550
Description
DETNET meeting session at IETF106
2019/11/21 1550
https://datatracker.ietf.org/meeting/106/proceedings/
A
B
We've
learned
something
at
this
meeting.
You
really
don't
want
to
be
the
session
right
after
a
really
nice
snack
break,
because
no
one
shows
up.
So
we
have
much
less
people
in
the
room
than
we
normally
do,
but
we
really
appreciate
you
showing
up
we'll
get
more
done.
That's
right,
so
I'm
Lou
burger.
This
is
Yanis
parkas.
We
have
our
secretary
Ethan
Grossman
here
and
our
welcome
to
that
Matt.
What's
that,
okay,
can
you
hear
me
apparently
I
have
to
eat
the
mic,
welcome
to
debt
net.
B
Our
agenda
is
online
and,
as
is
our
working
group
information,
please
take
a
look.
This
is
towards
we've
been
here
for
a
few
days,
so
everyone
here
should
be
familiar
with
the
note.
Well,
if
you're
not,
please
be
aware
that
everything
you
say
here
becomes
part
of
our
record
and
that
we
have
rules
governing
contributions
and,
if
you're
unfamiliar
with
them,
please
take
a
look
at
the
URL
at
the
bottom
of
the
page,
ITF
goerge
about
note
well
dot
HTML
for
the
meeting.
We
are
streaming
video,
we're
recording.
B
Also
the
everything
is
available
via
YouTube
or
audio
download.
We
are
also
using
our
joint
minute,
taking
via
ether
pod,
please
join
in
and
help
make
sure
that
your
comments
are
accurately
captured
and
just
help
us
out
to
have
accurate
minutes
really
appreciate
that
the
agenda
is
online
and
the
blue
sheets
are
circulating.
Please
do
sign
the
blue
sheets
that
helps
both
identify
who's
in
the
room,
as
well
as
how
big
a
room
we
get.
B
We
have
two
sessions,
the
first
session
you're
here
now,
so
thank
you
agenda
is
unmodified,
so
this
has
been,
what's
basically
been
posted
for
a
while
for
the
second
session.
This
is
the
second
session.
Great
we've
had
a
little
bit
of
a
change.
The
one
number
ten
and
bold
is
in
addition,
a
late
request
that
was
added
I.
B
Incremental
meetings
or
periodic
meetings
among
working
group
authors
that
all
of
those
are
advertised
on
less
than
open
to
all
we've
been
doing
a
pretty
good
job.
But
it's
really
important
when
there's
a
discussion
to
use
the
list
as
much
as
possible.
That
ensures
that
well
for
new
drafts
and
ensures
that
the
working
group
is
aware
of
what
you're
doing
for
working
group
drafts.
It
helps
ensure
that
we
have
good
communication
and
good
agreement
and
on
the
drafts
and,
as
we
know,
we're
here,
to
have
a
consensus
on
drafts
to
submit
for
publication
as
RFC's.
B
Since
the
last
meeting
we've
had
three
RFC's
published,
so
that's
that's
really
great.
We,
we
sort
of
were
a
little
slow
getting
going,
but
now
we
are
pushing
out
documents
which
is
a
reflection
of
the
work
that
those
in
the
room
and
those
on
the
list
have
helped
us
achieve.
So,
thank
you
for
all
your
work.
We
have
a
number
of
documentaries
that
have
gone
through
last.
Call
we're
gonna
talk
about
status
on
those
we
don't
have
to
talk
about
details
on
them
and
they're.
On
the
as
I
said
they're
on
the
agenda.
B
B
C
Mama
who
from
epfl
the
idea
is
that
for
the
next
draft
for
the
next
ITF,
you
are
planning
to
finalize
some
sections
that
are
related
to
the
calculation
of
the
delay
bound,
which
is
mostly
some
mechanism.
That
is
the
depth
that
can
be
used
in
debt
net
and
we
hope
that
we
can
finish
it
in
IETF
108,
which
is
in
I
guess
to
have
a
final
version
of
the
whole
draft
to
be
to
go
for
the
next
level
right
and
for
the
current
for
the
current
state.
C
B
So
where
are
we
in
terms
of
our
deliverables
and
milestones?
We
had
a
set
of
core
deliverables
that
were
called
out
when
the
working
group
was
formed.
We
are
really
in
good
shape
compared
to
where
we
were.
Let's
say
a
year
ago
we
have
our
overall
architecture
published.
We
have
the
core
data,
plain
documents
that
have
passed
last
call
and
the
the
debt
net
over
TSN
was
the
first
technology
subnetwork
technology
that
we
had
called
out
and
we,
those
documents,
are
closed.
B
You'll
hear
from
the
authors,
how
close
we
are,
hopefully
we'll
see
something
IETF
107
that
we
can
get
to
last
call.
The
flow
information
document
also
is
proceeding
along
and
we
do
hope
to
get
to
last
call.
There
was
some
discussion
that
you'll
hear
about
between
the
flow
information
model,
authors
and
the
yang
models,
authors,
and
there
might
be
some
additional
updates
based
on
that,
the
egg
models
were
is
on
the
agenda
and
that's
in
process.
The
the
other
part
of
that
was
pretty
important.
B
That
was
called
out
in
the
Charter,
and
my
initial
milestones
was
the
security
document
and
we're
looking
to
do
last
call
by
IETF
107.
That,
too,
is
on
the
agenda.
We'll
get
an
update.
One
of
the
points
that
came
up
with
our
Adu
is
whether
to
do
an
early
review
or
just
a
standard
review
from
the
security
area.
We're
actually
going
to
request
an
early
review
as
soon
as
the
authors
tell
us
that
they
think
it's
good
to
go.
B
My
are
no
last
week
for
myself
and
you
can
agree.
Our
hope
is,
is
that
that
is
becomes
a
complementary
activity,
whether
the
isg
chooses
to
do
it
as
a
its
own
working
group
or
within
this
working
group,
either
way
as
long
as
the
works
done,
I
think
will
I
think
we
should
all
see
it
as
a
benefit,
so
that
maybe
also
something
that
brings
in
that
we'll
have
to
watch
what
happens
with
the
isg
is
the
result
of
the
of
that
Boff.
D
E
David
black
yeah
told
me
security
documents:
oh
yeah,
a
lot
of
good
work
on
security
documents,
lot
of
good
texts
in
there.
However,
one
of
the
reasons
requesting
an
early
security
area
review
is
the
IHF
version
of
no
battle
plan
survives
initial
contact
with
the
enemy.
We
could
see
some
interesting
things
come
out
of
that
review
and
the
sooner
the
sooner
we
learn
that
the
better
great.
B
So
one
of
the
reason
one
of
the
items
here
was
a
set
up
for
someone
who
we
thought
would
be
in
the
room,
but
instead
we'll
just
go.
Talk
refer
to
his
may
list.
So
greg
mirskiy
sent
a
comment
to
the
list
about
the
OEM
for
MPLS
and
document,
and
we
had
oh
here
he
is
and
we
he
didn't
come
to
the
mic.
So
also
we'll
talk
about
it.
F
B
Okay,
thank
you
we
so
we
had
talked
about
this
at
the
last
meeting
and
there
was
some
moderate
support.
The
issue
with
why
we
didn't
do
an
adoption
until
now
was
there
was
very
few
people
who
would
read
it.
The
people
who
had
read
it
seem
to
have
liked
it,
but
very
few.
At
this
point
our
feeling
is
we're
gonna,
do
an
adoption,
call
and
see
if
there's
sufficient
support
and
if
there
isn't
we'll
go
we'll
go
from
there
right.
So.
F
F
Technical
problem
of
mapping
or
a.m.
session
between
and
points
are
on
to
their
death
net
IP
flow
that
to
be
monitored
so
I
send
some
proposal
appreciate
your
comments,
thoughts,
let's
discuss
it
in
the
mailing
list
and
then
once
we
reach
some
solution
that
we
agree
with,
then
we'll
get
to
their
consideration
for
adoption
of
second
document.
It's.
G
I,
have
hunger,
I
have
a
question
about
the
chatter.
Actually,
we
eat
bean,
it
helped
me
well,
we
are
contribute
in
the
work
of
SR
v6
bass.
That's
not,
and
the
others,
including
me,
are
very
very
confused
whether
this
part
of
work,
it
belongs
to
the
current
chatter
or
it
will
be
included
in
the
rich
header
part
I.
B
Think
it's
a
good
discussion
to
have
one
of
the
things
that
we'll
have
to
work
out
is:
is
that
work
happen
here
or
in
spring
generally
the
if
you're
talking
about
new
data
playing
mechanisms
you
go
to
the
group
that
owns
owns
that
unless
there's
an
agreement
to
do
it
elsewhere
right
now
they
own
the
data
that
data
plane.
So
we
would
need
agreement
from
that
working
group
to
do
it
here.
B
Without
that
agreement,
we're
gonna
assume
that
it's
gonna,
you
would
have
to
do
the
work
in
spring,
so
the
new
there
I
believe
you
have
a
new
data
playing
mechanism
and
that
probably
will
have
to
be
done
there.
But
it's
a
good
topic
to
raise
and
we'll
have
to
work
that
out
with
our
ad
and
the
ad
of
that
group,
it's
a
different
ad,
so
we'll
have
to
work
that
out
of
where
the
work
happens.
Actually.
G
I
am
totally
okay
with
doing
that
job
being
spring.
It
doesn't
matter
but
I
think
because
the
MPI
is
a
face
that
than
that
and
ip-based
and
that
belong
standard,
so
I
think
maybe
naturally
as
a
six
basis,
and
that
should
belong
to
ten
that
as
well
so
I'm
little
confused
and
considering
that
it
is
very
busy
in
spring
recently,
and
we
have
a
time
slot
in
spring
in
previous
session.
But
there
is
no
time
left
for
presentation
and
I
think
even
we
have
some
time
slot.
H
I
B
B
Be
the
working
that
working
group
chairs
call
and
then
the
ad
is
call
I
think
you
know
from
our
perspective,
like
that,
we
were
talking
about
related
to
wireless
we'd
like
to
see
the
work
done
and
where
it
happens
is
secondary,
but
okay,
but
they
they
sort
of
have
to
say
they
don't
want
it
before
we
can
say
we
want
to
take
it.
Okay,.
B
Right.
Thank
you.
Any
other
comments.
Please
feel
free
to
make
also
follow-on
comments
to
the
list.
Another
great
way
to
ensure
that
your
topic
is
included
in
the
discussion
for
IAT
f-107
is
to
have
a
draft
that
you
can
an
individual
draft
that
you
bring
forward
and
submit
towards
the
debt
networking
group
that
will
help
us
make
sure
that
we
don't
miss
your
topic.
B
The
this
is
our
last
slide
on
the
administrative
piece
we
want
to
give
the
working
group
a
heads
up
that
were
talking
about
doing
another
joint
session
with
with
I
Triple
E
at
OU
2.1
TSN.
We
had
a
really
good
session
in
Bangkok
after
the
IETF
at
the
start
of
the
the
Bangkok
I
Triple
E
meeting,
so
that
was
exactly
a
year
ago
and
we're
going
back
to
Bangkok
next
year
and
the
I
Triple
E
is
meeting
the
week
before
us.
So
the
thinking
is.
B
We
would
like
we'd
like
to
propose
and
investigate
doing
another
joint
workshop
or
meeting
on
the
Saturday
before
the
IETF,
so
the
I
Triple
E
ends
on
the
fryer.
We
would
immediately
the
next
day
we
would
have
the
this
meeting.
That's
the
straw
man
proposal.
This
is
not
yet
confirmed,
but
we
wanted
to
first
let
the
working
group
know
that
this
is
being
discussed
and
second
just
get
a
feeling
from
the
room
of
how
many
people
a
participated
in
the
last
one.
B
B
F
I
B
H
F
F
I
think
it's
okay,
that
we
have
the
first
more
like
introduction
to
technologists,
so
might
be
in
the
second.
We
can
do
something
for
both
parties
more
like
go
for
papers
and
people
will
submit
some
proposals
for
the
shorter
presentations
so
basically
break
it,
not
a
big
presentation
that
does
an
overview
over
technology,
but
people
talk
about
specific
use
cases
and
problems.
J
Hi
hi,
my
name,
is
manoj
welcome.
I
will
share
you
where
we
are
with
the
data
paragraphs.
The
first
presentation
is
about
the
framework.
You
might
remember
that
we
have
decided
to
have
a
building
block
approach
regarding
the
data
playing
drops,
so
that
is
the
first
of
the
a
draft.
I
will
speak
about
each
of
them.
So,
let's
start
with
the
with
the
framework.
J
The
current
version
of
the
framework
document
is
version
3.
This
content
is
quite
stable
and
it
it
is
providing
an
overall
framework
for
a
deterministic
network
data
plan.
So
it
is
covers
the
concept
and
the
considerations
that
are
generally
common
for
any
of
the
data
animistic
networking
data
plain
specifications
inside
the
document
we
have
sections
dealing
with
the.net
data
plane.
There
are
some
encapsulation
related
consideration,
deadness
specific
metadata's
are
also
covered.
We
have
framework
topics
on
the
IP
data,
plane
and
MPLS
native
line,
and
also
some
functions.
J
J
We
have
the
chef
area
review
for
this
document
and
there
was
a
very
last
call.
It
was
finished
and
the
beginning
of
Dober
and
we
have
received
pretty
good
comments:
how
to
improve
the
documents.
So
all
the
clarification,
a
deteriorate
changes
are
resolved
in
the
version
3,
which
is
the
current
version
so
based
on
that,
the
authors
think
that
it
is
ready
for
submission
for
the
EIS
G.
So
that
is
the
current
status
on
the
framework
document
and
it
questions
comments.
J
J
The
next
document
is
the
MPLS
data
planning
document.
It
is
dealing
with
the
that
net
data
plan
when
we
have
MPLS
based
at
work
in
case
of
MPLS.
We
have
description
for
both
sub
layers
for
the
service
sub
layer
and
also
the
forwarding
sub
layer
and
also
the
data
plane.
Procedures
are
defined
in
the
document,
so
the
flow
identifications
we
are
using
labels
and
for
the
segment's
number
that
not
control
guard
is
used
and
similarly
to
the
previous
data
plane
document,
we
have
a
management
and
control
playing
related
considerations
in
the
document.
J
During
the
change
of
the
document,
there
were
only
editorial
changes
and
fine
tuning,
so
the
technical
content
of
the
document
has
not
changed
when
we
have
created
the
version
3
and
now,
let's
speak
about
the
two
data
plane
documents
which
are
dealing
with
subnets
scenarios.
The
first
is
the
IP
over
MPLS
document.
In
that
case,
to
death
net
IP
nodes
are
interconnected
over
MPLS
subnet.
J
So
that
is
the
scenario,
but
the
document
covers
it
is
describing
the
data
plane
scenario,
the
encapsulation,
and
it
is
also
showing
four
IP
over
MPLS
procedures,
how
the
flow
identification
and
how
the
traffic
treatment
is
that
and
again,
as
for
all
the
data
plan
documents,
we
have
a
management
and
control
information.
Summary
the
same
apply
for
this
document
as
well,
and
we
have
created
version
3.
J
There
were
only
editorial
changes
and
fine
tunings
in
the
document,
so
it
is
also
pretty
pretty
quite
stable
and
last,
let's
speak
about
the
scenario
where
to
mpls
that
nodes
are
interconnected.
Over
IP
subnet
here
is
a
failure
on
the
figure
so
death
net
over
that
net
MPLS
over.
That
IP
is
what
we
are
covering,
and
this
is
also
the
procedures
that
we
are
describing
and
here
again
for
preparation
for
the
controller
plan
discussions.
The
considerations
regarding
management
and
control
is
also
included
in
the
document.
J
So
currently,
with
the
version
3
of
these
documents,
the
Shefford
view
were
done
and
we
have
also
a
very
brief
last
call.
It
finished
11th
of
November,
so
this
version
3,
is
the
latest
version
included
all
the
comments
that
we
have
for
the
document
during
during
the
work
and
the
others
think
that
these
documents
are
in
a
pretty
good
shape
so
that
they
are
ready
for
submission
to
the
ESG
and
it
combines
questions.
J
This
is
something
I
have
highlighted
on
the
slides.
This
is
not
yet
included
in
this
format.
I
will
make
a
version
for
for
that
document
in
order
to
make
that
happen,
and
there
were
also
comments
regarding
references
normative
and
informative
references.
I
think
this
is
also
something
should
be
cleaned
up.
That
was
also
recently
on
the
under
list.
Okay,.
J
J
B
B
K
J
Okay
and
now,
let's
speak
about
three
documents
where
we
have
was
a
new
content
from
the
compared
to
the
previous
version,
and
they
are
the
TSL
related
documents.
So
we
have
two
data
plain
documents
dealing
with
that
over
TSN
subnets
scenario,
when
we
are
interconnecting
IP
or
MPLS
that
not
nodes
over
TSN
network
and
the
last
one
is
dealing
with
the
scenario
when
TSN
domains
are
interconnected
by
a
dotnet
network.
J
For
these
documents
we
have
version
1
version.
0
was
created
after
the
split
of
the
IP
and
mpls
data
pin
solution
documents,
and
these
are
practically
the
new
documents
for
the
documents.
We
have
created
a
new
document
structure
that
is
valid
for
all
the
three
and
we
have
made
at
several
points
clean
up,
and
we
have
also
filled
up
with
some
tags
where
we
had
not
yet
text.
So
there
are
new
stuff
in
these
troughs.
J
First,
we
speak
about
when
to
IP.
Dotnet
nodes
are
interconnected
over
a
TSN
sub
network,
because
we
are
speaking
about
that
net
IP
data
plane.
They
should
take
only
about
the
debt
net
forwarding
sub
layer.
So
this
is
what
is
covered
in
the
document.
Service
protection
is
not
possible
end
to
end,
however,
in
the
TSN
sub
network.
This
is
something
what
you
can
provide
when
you
are
interconnecting
the
IP
that
net
nodes
on
the
right
side.
You
can
see
the
structure
of
the
document
just
below
here.
J
J
We
have
also
collected
the
management
and
control
information
related
aspects,
because
you
have
to
map
the
debt
NetFlow
us
to
TSN
streams
when
you
are
crossing
that
that
sub
Network,
the
document
is
containing
requirements
for
the
for
a
TSN
aware:
IP,
dotnet
node
such
nodes
are
member,
both
the
death-knell
domain
and
the
TSN
sub
network
within
the
TSN
sub
network.
That
IP,
that
not
node,
has
a
TSN
a
vertical
or
listener
role
and
the
death
net
flow
IDs
and
the
flow
related
parameters
requirements
are
met,
two
related
TSN,
Stream,
IDs
and
stream
related
parameters.
J
The
document
does
not
have
any
requirements
on
TSN
unaware,
IP,
that
not
nodes,
because
you
have
no
new
requirements
on
them.
However,
this
is
something
that
we
have
marked
in
the
management
and
control
consideration
that,
in
such
a
case
is
it
might
be
even
more
problematic
or
more
complex
to
to
start
such
a
triggering
between
the
two
domain,
because
the
IP
that
not
node
is
not
at
all
aware
about
that
sub
Network.
J
J
They
are
speaking
about
the
MPLS
data
plane,
so
both
the
service
and
the
forwarding
sub
layer
are
described
in
the
document.
You
can
do
service
protection
both
in
the
TSN
domain
and
in
the
MPLS.
That
not
domain,
however,
has
Service
protection.
Interworking
can
be
made.
This
is
something
that
is
left
for
further
study
in
the
current
version
of
the
document,
and
here
the
concept
is
very
similar
to
the
previous
one.
So
you
have
your
MPLS
that
not
node,
and
it
should
be
a
TSM
ever
to
occur
or
listener
from
the
TSN
Sun
network
perspective.
J
So
again,
you
have
to
map
the
MPLS
death
net
flows
to
TSN
streams
in
the
network.
So
that
means
that
that
these
MPLS,
that
not
knows,
has
a
TSN
ever
talk
or
listener
role.
The
flow
ideas
and
the
related
parameters
have
to
be
mapped
to
the
streams
and
the
related
parameters,
and
if
you
have
to
change
anything,
you
need
some
triggering
and
the
interaction
between
the
management
and
control
plane
of
the
dotnet
domain
and
the
TSN
domain.
J
J
J
J
There
are
some
TSM
related
functions
that
not
serve
a
related
service,
proxy
related
functions,
data
service
and
forwarding
sub
layer
also
described
in
detail,
and
the
Service
protection.
Interworking
is
also
left
for
further
study
in
that
case,
but
might
be
interesting
to
highlight
here
that
we
have
slightly
modified
or
created
this
scenario.
Specific
version
had
this
proxy
is
working
with
the
TSN
side
of
the
of
the
network.
If
you
look
to,
for
example,
to
the
architectural
document,
there
is
a
high-level
figure
here.
In
this
document
we
have
a
much
more
precise
depiction
of
those
scenarios.
J
Again,
management
and
control
plan
related
consideration.
You
have
to
map
the
data
that
flows
and
the
TSN
streams,
and
that
mapping
is
something
what
is
happening
at
the
service
box,
a
function
of
the
mpls
that
not
H
node
and
that
that
not
H
node
is
a
member
of
both
domain
and
it
is
acting
from
the
TSN
domain
perspective
as
a
as
a
tsa
relay
node.
J
J
Interworking
is
left
for
further
study,
so
this
is
where
we
are
with
these
documents,
but
we
intend
to
have
as
a
next
step,
to
collect
the
feedback
from
the
group
that
there,
whether
there
are
any
missing
items
or
something,
but
you
would
like
to
describe
in
more
detail
or
somewhat
differently
and
then
also
to
add
the
conformance
language
to
these
data
plane
documents.
So
that
is
the
plan.
K
Ethan
Grossman
I
note
in
the
security
consideration
sections
of
these
various
drafts
that
they're
they're,
quite
small
and
in
looking
at
the
security
considerations
for
the
other
data
plane
drafts
the
iclicker
data
planes,
IP
and
mpls
we've
been
looking
in
the
security
group
for
things
that
are
time-sensitive,
specific
and
data
plane
specific.
Have
you
given
much
thought
to
that?
Are
you
confident
that
there
isn't
anything
specific
to
the
TSN
of
the
security
considerations
for
fir
these
or
or
do
you
think
that
that's
a
subject
that
needs
further
study.
J
K
Yeah
one
question
that
came
up
and
just
discussing
the
structure
was
well
say:
we
publish
the
security
considerations
draft.
Then
we
get
another
data
plane
like
some
wireless
thing
or
something
then.
Obviously
this
draft
will
be
closed,
so
everything
will
have
to
go
into
the
data
plane
specific
document,
so
I
was
just
curious,
whether
it's
a
good
idea
to
keep
using
this
model
or
whether
we
should
figure
we're
going
to
migrate
to
a
model
where
that
information,
that's
specific
to
that
data
plane
goes
in
the
data,
plane,
drive
I.
J
I
Can
I
just
have
a
communication
to
your
question,
so
you
because
actually
the
security
document
was
gated
by
the
base
data
plane
actually
and
the
architecture,
and
my
understanding
is
you
want
to
avoid
any
kind
of
situation
like
saying
this?
Is
it
for
now
in
the
security
document
and
from
a
borderline?
If
there
is
any
new
data
plane
draft
that
has
to
do
with
its
own
security
considerations,
did
I
get
to
find
that
that's
what
you
are
after
yeah.
K
I
mean
I,
don't
see
how
else
to
do
it
unless
we
pull
all
the
stuff
out
and-
and
it's
just
it
goes
there
now.
But
since
those
drafts
have
already
been
last
called
and
we
couldn't
find
anything
anyway.
We're
sort
of
in
at
the
moment
we're
in
a
consistent
state
because
we
couldn't
find
anything.
But
if
we
go
forwards
and
we
do
find
something
that
it
might
be
interesting.
But.
I
B
K
B
K
B
B
B
J
B
G
Some
go
I
just
suggest
that
maybe
we
can
send
this
part
work
also
to
the
actually,
because
I
think
TSM
people
may
very
interested
in
how
to
do
the
mapping
between
the
tenet
and
Tessa,
because
in
the
previous
joint
meeting
a
lot
of
people
they
are.
They
are
curious
about
how
to
use
their
three
deterministic
technologies
and
how
to
use
them
with
TSN,
so
I
think.
Maybe
there
will
be
a
lot
of
potential
view
reviewers
there
yeah.
Actually,
that
is
just
a
suggestion.
Okay,
so.
B
G
B
A
B
I
I
So
the
the
flow
information,
as
the
title
says,
plus
the
information
mundo
for
the
service,
and
this
is
from
the
from
the
document
that
both
the
figure
and
the
text,
what
is
an
information
model
and
what
is
data
model?
So
the
subject
of
this
document
is
the
flow
information
model
and
the
service
information
model
and
data
models
are
the
subject
of
the
yank
document.
You
will
hear
about
after
the
my
presentation.
I
So
what
happened
since
the
last
IETF?
We
had
version
four
for
the
last
IDF
and
two
updates
since
then
version
6
and
version
5
in
version
5.
We
had
a
number
of
editorial
updates
in
up
in
the
language
and
current
many
clarifications
in
the
text
and
in
in
the
attribute
formats.
For
example,
making
it
clear
in
that
well-known
names
are
attributes
and
the
formally
empty
placeholder
Security
section
has
been
filled
in
security.
I
I
This
is
a
security
parameter
index
which
is
a
kind
of
an
identification
tag
if
IPSec
is
used,
so
that
has
been
added
to
the
parameter
list
for
fly,
identification
and
just
a
reminder.
This
is
the
structure
of
the
attributes.
This
is
what
we
is
captured
in
in
the
draft.
So
as
I
as
I
said,
the
key
parts
are
data
flow
and
the
service
information
with
the
parts,
but
it's
very
important
input
for
these.
I
This
first
question:
we
keep
repeating
to
the
group
and
this
is
there
any
missing
attributes,
and
this
I
would
like
to
ask
people
to
review
that
often,
and
then
we
give
comments
on
the
last
two
item.
Actually,
we
had
a
working
session,
as
you
saw
an
email
list
last
night
and
it's
very
important
that
to
ensure
that
this
document
and
the
end
document
absolutely
in
line.
Actually,
we
find
some
gaps,
kaesong
we'll
talk
about
it
in
the
next
slide
in
detail,
and
this
leads
to
the
other
question.
I
We
told
before
that
it's
a
the
flow
information
model
draft
is
ready,
as
is
for
working
with
plastic.
All
now,
actually
I
would
say
after
filling,
in
these
gaps
between
the
two
in
some
form,
we
think
that
authors
think
hey.
We
are
close
and
ready
for
working
class
Co.
So
that's
it
on
on
my
side,
David
David.
H
E
Actually,
a
bigger
scope,
question
of
which
is
the
car
which
is
the
horse,
and
how
do
we
cope
with
it,
which
is
MPLS,
om,
looks
like
a
fairly
clean
add-on
via
the
ACH.
Ipo
am
looks
like
anything,
but
how
far
along
do
we
have
to
get
with
IPO
am
to
figure
out
that
we
don't
need
anything
else.
It's
probably
gonna
be
turn
out
to
be
mostly
in
the
IP
data
playing
draft.
If
we
wanted
up
neat
needing
to
do
something
clever
about
flow
identification,
get
the
OEM
flows
to
behave.
I
A
good
question
and
actually
I,
haven't
really
seen
the
discussion
on
this
in
the
list.
So
yeah.
That
seems
to
be
a
bit
of
an
open
question.
No
ideas
have
been
bought
so
far
and
that's
a
good
question
in
the
sense
of
how
do
we
get
done
because,
as
you,
my
understanding
of
Greg's
points
and
proposal
was
to
not
to
bind
together
the
MPLS
and
IP
om,
but
let
the
MPLS
OEM
progress
and
then
progress
later
as
we
can
with
the
IPO
am
yeah.
E
I'm
not
sure
what
I'm
suggesting
we're
observing
is
that,
as
you
said,
the
Empress
om
OM
is
clean.
It's
pretty
clear
that
that
that
know
how
to
tag
the
head
identify
the
OEM
flows
as
Oh
am
I
my
suspicion
is
that
Greg's
proposal
affects
IP
flow
identification
and
hence
is
gonna
hit.
He's
gonna
hit
the
IP
data
playing
draft
is
gonna
hit
this
one
and
I.
Do
you
want
I
guess
the
question
the
to
you
is
chairs
is
how
how
much
do
you
want
somewhere?
B
B
As
chairs
we've
said,
we're
going
to
define
the
core
get
those
out
and
keep
pushing
along
and
duo
a.m.
when
it
shows
up.
We've
also
has
made
the
technical
call
that
OAM
is
going
to
have
to
follow
the
path
of
the
flows,
so
has
to
meet
our
flow
definitions,
and
we
certainly
have
had
some
conversations
of
ways
that
could
be
done,
but
we
don't
have
a
document
it
at.
You
know
greg
that's
the
status
right.
We
don't
have
a
document
that
gives
us
an
answer
yet,
so
we
don't
have
confirmation
of
that.
E
B
E
Okay,
I
think
it's
a
question
which
is
that
that
the
working
group
consensus
is
believed
to
be
that
the
IP
data
plane
draft
needs
to
move
forward
without
Prok
without
further
further
delay,
as
OAM
gets
unscrambled.
If
it
impacts
the
IP
data
plane,
we
get
to
complete,
we
we
get
to
come
back
and
revise
that
and
deal
with
that
when
we
get
there
right
and
just.
B
L
M
M
B
E
I
L
L
So
if
you
have
a
ripple
domain
and
so
you're
using
ripple
to
to
do
the
routing
inside
that
domain,
then
there
is
work
at
a
troll
which
actually
enables
to
what
do
what
we
call
rod
projection,
which
is
really
installing
a
route
from
the
roots
directly
into
the
network,
and
this
this
rod
is
what
we
call
a
track
in
six
dish.
It's
a
complex
route
have
been
something
very
akin
to
what
we
do
here
and
it
is
signaled
in
the
packet
using
a
hop-by-hop
header,
which
contains
some
information
which
is
akin
to
a
vrf
information.
L
So
our
local
and
global
he
arrives.
So
the
local
ones
really
tie
the
destination
of
the
packet,
which
is
the
exit
of
this
track
with
a
number
which
is
locally
significant
there,
and
that
basically
tells
you
which
routing
table
you
need
to
look
at
for
the
spider
and
you
can
have
huge
numbers
of
those
things
in
a
ripple
net.
L
So
that's
how
we
actually
signor
not
really
the
flow,
but
the
path
that
this
the
flow
is
supposed
to
go,
which
also
means
that
you
could
place
the
OAM
and
the
data
on
the
same
path
and
they
will
follow
it
to
the
destination,
which
is
the
case.
I
wanted
to
give
to
Stuart
that
we
actually
have
one
case
where
we
know
how
to
merge
the
flow
and
the
IOM
into
the
same
thing.
So
is
it
something
want
to
capture
here
or
do
you
see
it
as
an
exception?
That's
not
interesting!
So.
L
I
B
So
we
actually
the
mechanisms
that
we
built
the
IP
data
plane
on
or
closer
to
policy
routing.
So
if
you
look
at
policy
routing,
you
can
do
very
similar
things
and
you
don't
have
to
have
topology
and
it
you
don't
have
the
topology
IDs.
You
have
an
MRT
or
the
SIDS
that
you
have
in
spraying.
You
just
have
policies
so
I
think
what
you're
saying
is.
We
would
want
that
we
should
pursue
a
path
that
maps
different
flows
to
the
same
basically,
policy.
L
The
policy
tells
you
which
flow
is
good
in
which
rib
and
now
you
stamp
the
rib
in
the
packet
and
the
packet
follows
this
rib.
The
question
is:
this
is
how
we
signal
the
equivalent
of
a
flow
in
our
packets.
It
is
something
worth
capturing
it.
You
are
missing
attributes
well
that
that's
a
flow,
a
notification
attribute,
but
let
me
a
flow.
Its
topology
but
I
see.
H
I
L
E
G
G
This
this
draft
is
accepted
as
a
working
group
document
after
IETF
well
and
in
the
first
version
we
separate
the
done
edit
apology,
young
another
document
and
the
yen
version.
We
received
some
feedback
from
the
working
group
and
we
update
the
following
attributes.
We
end
the
sequence,
number
generation,
considering
the
OEM
and
we
end
then
a
service
decapsulation
and
also
then
I
transfer,
tano
decapsulation
in
version
3.
We
do
a
lot
of
work
about
the
configuration
structure
update
in
item
well
for
and
while
5
in
version
4,
which
is
the
current
version.
G
We
modify
the
scope
of
the
10
and
Yamoto
merely
to
go
aligned
with
the
information
model
work-
and
here
is
the
previous
word.
Basically,
we
define
a
10
and
a
configuration
module
which
is
defined
for
that
net
flow
paths,
built
building
of
flow
statements,
reporting
and
then
add
functions
configurations
we
defined
through
4
modules
inside
the
this
young
model,
which
include
the
attributes
of
application
flow
survey,
sub
layer
and
forwarding
sub
layer
and
some
network.
G
This
is
based
on
the
net
data
plan
protocol
stack
defined
in
the
architecture
document
and
in
this
world,
I
tried
to
do
some
modification
to
go
along
with
the
structure,
as
the
previous
slide
show,
because
in
the
information
model
there
is
that
another
service
attributes.
So
we
end
the
than
a
service
module
to
include
the
service
quality
attributes
such
as
the
latency,
the
lost
the
miss
Audrey,
and
we
also
end
the
endpoints
attributes
to
indicate
the
start
point
and
the
end
point
of
the
dinosaurus,
and
maybe
the
encapsulation
type
attributes
is
also
needed.
G
G
But
after
some
discussions
with
the
other
of
an
information
model,
there
is
a
call
meeting
and
we
also
meet
each
other
yesterday
and
we
find
that
these
two
Mojo's
models
are
still
not
well
aligned.
Yet
so
the
mapping
between
the
information
model
and
llamado
are
still
to
be
defined
and
we
plan
to
work
together
after
this
meeting.
Perhaps
we
will
have
a
call
meeting
every
week
to
make
this
work
down,
and
the
picture
shows
that,
in
the
left
hand
is
the
information
model.
G
We
see
that
there
are
three
boxes
and
in
the
right
hand
that
is
the
ten.
Oh
sorry
I
write
this
wrong.
This
is
the
the
structure
of
the
young
model
and
we
have
four
elements,
so
maybe
how
to
map
the
information
model
attributes
to
the
young
model
attributes
and
make
it
very
easy
to
understand.
There
is
our
next
step
work
and
that's
all.
Thank
you.
I
H
E
David,
black
wearing
transport
area,
tech,
advisor
hat,
small
request,
boo-boo
top
out
in
the
past,
as
you
work
towards
the
next
revisions
draft,
which
looks
like
a
lot
of
work.
There
is
still
in
this
version
the
dscp
and
the
DSA
bitmask
pair.
That
needs
to
be
changed
with
dscp
list.
Just
it's
it's
small
item
that
should
be
double
sooner
or
later.
Thank
you,
I
think.
B
E
E
G
B
Thank
you,
so
we're
actually
running
a
bit
ahead,
which
is
right,
which
is
pretty
rare,
which
is
actually
really
good,
because
our
tech
advisor
David
black
can't
be
here
for
the
second
session
and
really
wanted
to
be
here
for
the
security
document.
If
the.
If
even
if
you're
willing,
can
you
go
now
great,
so
we're
gonna
move
that
slot
up.
M
K
So
the
intent
of
the
draft
is
to
be
a
reference
in
a
toolkit
for
network
designers
who
have
not
necessarily
dealt
with
time-sensitive
networks
before
so.
This
is
relatively
new
in
the
IETF,
so
we
figured
we'd
have
a
clearinghouse
for
that
kind
of
information.
So
this
document
doesn't
address
the
general
considerations
for
security
for
IP
and
mpls
networks.
We
leave
that
to
the
existing
documentation,
we're
very
focused
on
only
the
time
specific
aspects
of
it
and
the
relation
of
this
drafts
to
the
security
considerations.
K
Sections
in
the
other
debt
net
drafts
is
that
basically,
each
of
those
drafts
is
to
have
its
own
security
section,
addressing
issues
specific
to
that
particular
draft
topic,
but
then
having
a
reference
to
this
draft
to
cover
all
of
the
more
general
technology,
independent
and
and
other
considerations.
That's
that
way
we
don't
have
to
duplicate
these
many
pages
in
each
draft.
K
So
at
the
moment,
the
technology
independent
section,
in
other
words,
regardless
of
whether
you're
on
an
IP
based
network
or
MPLS,
that
section
is
fairly
mature.
At
this
point.
This
drafts
been
running
for
nigh
on
two
years
and
we've
had
a
fair
number
of
eyes
on
that
part
and
if
there's
a
fair
amount
of
organization,
there's
a
few
little
bits
to
fit
in
and
fill
in,
but
that
part's
pretty
mature.
K
The
thing
that
we
thought
we're
really
going
to
do
is
the
next
big
thing
was
the
IP
and
mpls
specific
sections
we
thought
well,
there's
got
to
be
stuff,
that's
specific
to
both
time-sensitive
networks
and
the
IP
implementation
versus
the
MPLS
implementation.
So
we've
had
as
many
people
as
I
could
manage
to
wrangle
into
discussing
this.
Look
at
this
and
so
far
the
result
is
that
we
haven't
really
found
any
unique
that
are
both
related
to
time-sensitive
and
not
covered
in
the
general
case,
but
are
specific
to
that
data
plane.
K
So
we
have
later
I
have
hoping
we
can
have
a
little
bit
of
conversation,
but
maybe
it'll
just
get
deferred
to
the
list.
But
my
sense
is
that
if
you've
ever
read
read
the
Gladwell
book
about
blink
there's
this
thing
where
people
who
have
been
doing
something
for
a
long
time
just
have
a
certain
sense
of
intuition,
but
it's
not
just
intuition
from
nowhere.
It's
intuition
from
many
years
of
working
on
it.
So
I
guess
what
I
was
asking
is
that
if
you
could
think
about
that
statement,
I
mean
at
the
moment.
K
Our
stance
is,
there's
nothing
technology
specific
about
these.
So
we
got
sections
in
the
Security
draft
that
say
IP,
nothing
specific,
it's
all
just
the
general
stuff,
MPLS,
nothing
specific,
just
the
general
stuff.
Does
that
ring
true,
or
does
that
leave
a
bad
feeling
in
your
stomach,
because
I
haven't
gotten
anybody
to
come
with
anything
specific,
but
I'd
settle
for
a
general
feeling
about
it.
So
that's
just
one
way
to
approach.
What
to
me
at
the
moment
is
kind
of
an
intractable
problem
is
trying
to
figure
that
out.
K
K
How
is
anybody
going
to
review
the
security
draft
without
understanding
what
the
criteria
and
the
requirements
are
so
I
said
well
collect
all
these
things,
that's
as
close
as
we
have,
and
that
way
people
can
look
at
those
and
say
well.
This
is
kind
of
what's
expected.
Do
we
think
that
we're
covering
the
territory?
So
my
question
is
well
what
do
I
do
with
that
stuff
I
mean:
do
I,
leave
it
in
the
draft.
If
I
do,
then
that's
our
a
process
of
updating
it
and
make
sure
I've
got
all
the
stuff.
To
date.
K
That's
been
added,
since
you
know
that
was
last
worked
on,
which
was
many
months
ago,
or
do
we
just
chuck
it
and
figure
it
doesn't
really
belong
in
the
security
draft
anyway.
Interesting
questions
to
ponder.
We
may
have
a
second
for
a
discussion
if
we
do
and
we'd
like
to
I'd
like
your
employment,
I
will
okay,
so
I
look
forward
to
your
input
any
minute
now
right
now,
discussion,
okay,
so
there
were
three
questions
that
I
had
intended
to
ask
one
of
them.
K
The
third
one
we've
already
actually
managed
to
resolve
about
the
security
Directorate
review.
Is
it
going
to
be
before
after
working
group
last
call,
and
we
decided
that
we
would
go
for
it
at
the
beginning
of
last
call.
We
would
also
submit
for
an
early
review.
In
other
words,
it
would
be
four
before
it
was
passed
to
the
iesg.
We
would
also
have
the
security
Directorate
have
a
look
at
it
first,
in
parallel
with
our
working
group.
Last
call
so
I'm
happy
to
have
that
result.
K
E
I
did
but
some
people
who
drew
a
blank
on
airplane
technology,
specific
threats,
I
thought
are
come
to
the
mic
and
explain
why
my
gut
feel
is
that
it's
okay
or
I'm
not
really
upset
about
it
and,
let's
just
see
if
I
can
get
somebody
up
to
the
up
microphone
to
debate
me
and
we'll
learn.
Something
reason
is
that
the
security
reasons
draft
is
very
much
written
from
a
threat
model
perspective.
It
takes
a
general
functional
model
of
time,
sensitive
networking
and
outlines
all
the
various
threats
that
could
disrupt
that.
E
At
that
level,
it's
got
pretty
complete
threat
coverage
now,
if
I
plug
a
data
plane
in
underneath
that
time,
specific
of
networking
I
wanted
up
we're
finding
that
general
function
model
is
specific
manifestations
data
plane.
The
threats
haven't
changed,
but
how
they
impact
the
data
plane
probably
has,
but
with
the
security
drive,
haven't
been
written
with
primarily
in
terms
of
threats
and
not
in
terms
of
specific
manifestations
in
the
data
plane.
The
fact
that
we
can't
find
any
new
threats
against
the
data
plane
is
not
that
big,
a
surprise.
E
Think
you
cast
a
die
I
think
divers
cast
awhile
ago
to
write
the
security,
the
overall
security
draft
as
an
overall
deterministic
networking
security
draft,
and
that
leads
to
its
current
Phet
model
structure.
So
I'm,
not
criticizing
that
try
and
just
sort
of
have
a
look
at.
Is
there
a
gap
there
and
the
answer
is
well?
No,
it's
our
they
did
did
did
implementing
deterministic
networking
on
a
specific
data
plane.
Add
new
threats
to
deterministic.
Networking,
perhaps
not
know.
K
E
E
K
B
So
we
still
are
running
a
little
bit
ahead,
but
I
think
if
we
try
to
squeeze
in
another
we
might
run
it
run
out
of
time
in
the
session.
So
what
we're
gonna
do
now
is
break
until
the
second
session.
The
second
session
is
back
in
this
room
in
half
an
hour.
So
instead
of
a
20-minute
break,
we're
gonna
have
a
half-hour
break,
so
see
you
all
here
at
5:40.
M
That's
all
well,
that's
history
and
that's
what
people
have
been
doing.
That's
we're
trying
to
move
away
from
the
other
thing
too.
We
might
want
to
watch
out
for
a
lot
of
people
when
they
think
they
buy
a
wire
or
serve
as
an
internet
service,
for
example,
from
their
a
turbulent
area.
I'll
find
what
they
think,
thereby
they're
buying
a
moment
sex
right.
Yes,
well.