►
From YouTube: IETF109-DETNET-20201119-0730
Description
DETNET meeting session at IETF109
2020/11/19 0730
https://datatracker.ietf.org/meeting/109/proceedings/
A
Hi
everyone
welcome
to
this
meeting.
This
is
the
meeting
of
the
net
working
group
in
itf
109.
A
A
This
is
the
itf
neutral.
Our
rules
please
check
if
you
are
not
familiar
with
them,
note
that
everything
you
say
becomes
a
part
of
our
permanent
record
as
a
contribution.
A
The
blue
sheets
are
automatic
and
they
are
automatically
generated
from
the
meter
committing
you
don't
have
to
bother
with
it,
but
please
joint
note
taking
so
from
this
time
we
are
using
the
integrated
note,
taking
the
new
naughty
note-taking
tool.
The
coding
here
is
the
link,
and
it
is
a
great
help
for
four
minute
taking
and
double
checking
each
everything
is
fine
in
the
minute.
So
please
join
us
and
join
us
and
help
with
it.
A
Taking
the
online
agenda
and
the
slides
are
available
at
the
usual
place
at
the
net
meeting,
folder
or
page
and
the
usual
stuff
I
mentioned
already
so
this
is.
Our
agenda
has
not
been
changed
for
a
while.
We
are
actually
going
through
a
couple
of
working
group
drafts
and
some
new
contributions.
A
I
will
not
read
this
out
you
really
during
the
waiting.
I
would
remind
you
about
the
ipr
process.
We
do
call
for
ipr
at
multiple
stages.
We
follow
the
ietf
ipr
process
and,
in
addition,
code
for
ipr,
at
specific
stages,
for
example,
before
a
working
group
goes
for.
The
last
call.
A
A
We
have
the
three
rfcs
published
and
we
have
made
progress
with
the
data
plane
drafts
all
both
the
the
the
framework
and
the
ip
are
really
getting
ready.
A
They
are
at
48
so
being
really
finalized
and
a
couple
of
more
from
the
core
data
plane
drafts
are
with
the
rfc
editor
and
the
the
mpls
and
the
ipo
for
mpls
as
well,
and
we
have
the
fifth
one
out
of
the
ones
we
call
core
data
plane
once
the
mpls
over
udpip.
A
For
this
we
have
requested
the
publication.
So
this
is
it
at
the
va
finder
review
stage
as
well.
A
We
have
two
more
drafts
for
publication,
requested
the
flow
information
model
and
the
net
security.
These
have
been.
These
are
have
been
reviewed,
we've
got
isg
review
comments,
and
these
drafts
have
been
updated
and
to
be
scheduled
for
the
very
final.
A
Review
we
have
a
few
three
ts
and
data
plane
related
drafts
that
post
working
group
last
school,
so
these
ones
are
progressing
as
well.
Since
we
are
discussing
this
on
the
list,
there
is
no
representation
or
during
this
meeting
everything
is
going
on
in
the
list.
A
We
have
two
working
group
drafts
that
are
not
on
the
agenda
for
today.
These
are
the
mpls
and
the
ipom
drafts,
but
we
have
a
oem
topic
for
discussion
sort
of
more
of
a
framework
when
it
comes
to
oem.
So
that's
the
online
discussion
for
today.
A
Yes,
you
are
are
experiencing
and
all
of
our
experiencing,
we
have
been
working
remote
for
a
while
and
it
may
stay
for
a
while
for
some
time
more.
So
we
would
like
to
keep
momentum
and
then
use
all
the
possibilities
we
have
for
that.
We
use
the
mailing
list
as
usual,
that
has
been
used
always
so,
please,
please,
be
very
active
in
the
mailing
list.
A
Consensus
is
determined
in
the
mailing
list.
They
also
have
virtual
meetings.
Interims
can
be
scheduled
as
as
needed.
We
had
one
in
october
for
yang
or
them
they're
kind
of
dedicated
for
the
progressing.
The
young
work
and
we
can
schedule
interim
really
as
needed.
So
so
please
make
proposals.
If
you
see
the
need-
and
of
course
we
I
just
also
think
of
when
it
is
useful.
A
A
We
have
the
webex,
the
working
group
webex,
which
is
available
for
for
the
working
group
members
to
have
meetings
and
and
discussions
just
ask
us
if
you,
if
you
think
that
would
be
useful
and
we
have
a
regular
ongoing
meetings
of
these
kinds
or
progressing
yang.
But
there
could
be
other
topics
like
oem,
for
example,
that
could
benefit
from
such
meetings.
A
Let's
go
to
the
first
presentation,
which
is
the
young
update.
A
C
Good
morning,
so
I'm
going
to
give
an
update
on
the
net
yang.
As
janos
mentioned,
we've
been
meeting
weekly
on
mondays,
not
exactly
what
sure
in
your
what
time
in
your
time
zone,
it's
nine
at
nine
a.m.
Nine
a.m.
My
my
time
zone,
I
think
I
I
I've
forgotten
all
the
things
anyways,
here's
the
list
of
the
the
people
that
typically
attend
the
meeting
go
on
to
the
next
slide,
so
the
status
we've
we've
been
working.
C
We've
we've
published
an
an
interim
version
of
the
the
draft
for
people
to
view
we've
merged
yang
models
and
we're
working
on
some
yang
lint
data
instances
for
various
configuration
scenarios.
C
If
you
have
a
look
now,
you
should
see
that
in
the
draft-
and
I
think
those
are
easier
to
to
see
the
things
and
that
helps
us
get
the
these
point
about
checking
the
terminology
and
the
consistency
for
clarity.
So
we're
doing
that
and
we've
we've
got
a
number
of
models,
we're
working
through
about
six
to
eight
models.
Right
now
we
put
three
in
the
draft:
we're
we're,
checking
consistency
against
the
data
plane
drafts
and
we're
updating
the
reference
pointer.
C
So
we
currently
have
some
comments
from
rashad
that
we're
working
through
have
to
get
the
the
team
together.
So
again,
if
you're
interested
in
this
meetings
are
monday
morning
or
you
can
look
at
the
draft
and
you
can
give
us
some
feedback
next
chart,
please.
C
So
here's
a
history
of
the
the
versions
and,
like
I
said
version
nine
is
out
there
and
that
was
just
published
this
week.
Go.
C
On
so
this
diagram,
you've
seen
it
before
it
just
represents
the
the
main
pieces
of
the
the
model
that
we've
been
working
on.
The
types
of
configurations,
so
ip
over
mtls
is,
is
the
typical
one
and
we've
been
we've
been
checking
out
the
various
scenarios
for
the
for
various
pieces,
so
the
configuration
through
the
application,
the
service
sub
layer
and
the
forwarding
sub
layer
is
all
in
there
and
the
drafts
and
reds
are
the
ones
that
are
are
driving
it
right
now
and
the
other
ones.
C
And
part
of
this
is
we're
also
synchronizing
with
the
flow
model.
I
there
is
a
little
bit
of
difference.
If
you
look
at
the
flow
model
we
align
with
the
flow
model,
but
because
the
yang
representation
is
hierarchical
versus
the
way
the
flow
model
is
described,
there's
a
little
bit
of
difference,
but
we
do
have
all
these
elements
in
the
various
pieces
in
inside
there.
C
C
Illustration
of
the
types
of
things
that
we're
doing
in
in
terms
of
aligning
the
terminology
and
just
going
through
and
and
making
some
changes
for
consistency
and
we're.
Just
in
the
midst
of
doing
that.
So
just
cleaning
up
the
model
as
well
as
checking
out
the
yang
lint
that
it
it
makes
sense
as
a
readable.
C
Configuration
go
on
to
the
next
chart
and
just
to
give
you
an
idea
of
the
different
configurations
we
do
so
we
we
have
configuration
for
the
egress
edge
node,
starting
on
the
right
hand,
side.
We
have
configuration
for
the
relay
node
and
the
the
transit
node
so
and
supporting
we're
now
support
in
the
model.
We
support
aggregation
at
all
these
levels,
so
for
a
while,
we
had
aggregation
in
some
areas,
but
not
everywhere.
We
think
we've
got
all
the
aggregation
in
there.
C
D
Thank
you
don.
You
mentioned
you're,
doing
trying
to
do
some
consistency
with
terminology
and
naming,
and
you
showed
an
example
where
it
looks
like
you've
introduced
a
new
term.
Can
you
talk
a
little
bit
about
you
know
what
what
strategy
you
all
are
following
and
if,
if
you
think
you
need
new
terms,
what
are
they.
C
Well,
hopefully,
we
didn't
introduce
a
new
term,
but
we
haven't.
We
haven't
rationalized
that
so
that's
a
that
because
we
just
been
changing
the
model
terminology.
That's
still
a
bit
of
a
work
in
progress,
but
we're
trying
to
review
that
to
make
sure
that
we're
consistent
with
the
data
plane
drafts
and
the
flow
the
flow
model
yeah.
It's
the.
C
Yeah,
so
the
the
upper
so
so
that
that's
been
introduced
right
now
to
to
show
that,
when
we're
aggregating
at
the
various
layers
in
terms
of
the
the
model,
I
don't
know
whether
that
will
stick.
We
it's
just
new
terminology
that
that's
happened
in
this
version
and
we've
just
been.
You
know
working
our
way
through
it,
so
that
really
hasn't
gone
through
a
comment
review.
D
E
Hi,
this
is
jason
speaking.
Thank
you
don
for
your
presentation
and
some
brief,
a
response
to
lu's
comments.
E
Actually,
we
are
not
going
to
introduce
new
terminologies
in
this
young
model
and
all
the
terminologies
will
align
with
the
previous
data
plan
documents,
and
here
we
doing
the
naming
updates
just
to
make
the
young
model
more
easy
to
understand,
for
example,
the
aggregation,
what
kind
of
aggregation
and
how
to
do
that.
So
there
is
no
new
terminology,
but
just
to
updating
some
naming
and
do
the
clarification
and
another
comment
is
some
supplement
about
our
work.
E
Actually,
maybe
you
all
notice
that
don't
go
over
the
aggregation
part
so
quickly,
because
we
have
to
do
the
presentation
in
the
in
terrorism.
So
if
people
are
interested
in
this
part,
please
go
to
the
terrorism
of
the
terrorism
and
there
we
have
a
lot
of
details
about
what
we
have
done
and
also
comments
that
are
helpful.
Thank
you.
A
Thank
you
very
much.
I
don't
see
anybody
else
in
the
queue,
so
I
thank
you
really
for
the
team
for
for
progressing
this
work,
and
now
this
is,
I
guess,
our
major
next
step
to
complete.
So
everybody
is
really
welcome
to
contribute
and
review
and
help
finalizing.
A
So,
let's
move
to
the
next
presentation,
which
is
about
the
bounded
latency,
I'm
not
sure
who
will
present.
G
F
F
F
A
quick
reminder
of
the
current
state
is
this
is
a
informational
track
and
the
content
includes
the
timing
model
for
flow
creation
and
relay
node
model
and
in
order
to
get
the
end
to
end
delay
bond
we
separate
into
two
part:
first,
is
the
non-curing
delay
bond
and
second,
is
for
the
queuing
delay
and
in
the
queuing
delay
we
may
separate
it
into
many
scheduling.
There
are
examples
given
in
the
section
6
and
based
on
the
end-to-end
delay
upper
bound
in
the
section
5.
F
F
F
We
do
not
want
to
detail
the
scheduling
in
this
draft,
but
we
all
want
to
make
the
draft
currently
more
concise
and
conformant
to
the
network
group
and
the
main
changes
is
in
the
section
5.
We
update
the
formula
for
backlog
and
in
the
section
6
we
simplify
the
time-aware
shaping
and
also
simplify
the
insert
section
to
make
it
more
clear
and
one
major
change
is
that
we
modify
a
lot
in
the
second
queueing
forwarding
and
previous
version
is
for
the
street
buffer
scheme.
F
F
Details
also
can
be
referred
to
the
rgb
tsn,
so
we
look
forward
for
your
comments
in
this
main
changes
here.
Please
go
on
and
just
a
quick
information
for
the
two
buffer
cqf.
The
delay
analyzed
for
the
end
to
end
delay
upper
bound
and
the
cqf
is
we
have
to
buffer
a
buffer,
a
and
buffer
b,
consider
that
they
are
switched
at
every
cycle.
F
F
A
A
Thank
you.
Thank
you.
Thank
you
for
the
presentation
and
I
think
it's
we
should
discuss
going
for
a
working
group.
Last
call
for
me.
It
looks
very
good
that
there
is
progress.
A
A
Not
hearing
anybody,
it
sounds
like
a
good
move
to
to
go
to
glasgow,
so
we
will
synchronize
on
that.
Among
chairs
and
authors.
H
Hi
hello.
Yes,
I
can
hear
you
good,
I'm
tom
hondu
from
china
mobile.
I
have
a
project.
This
iot
build
a
description
of
this
in
size,
okay,
hello,
everyone.
H
H
H
They
are
used
to
provide
connection
service
for
object,
display
under
control
plan
and,
though
not
in
the
standardization
scope
of
3dpp.
Some
of
the
lg
requirements
also
motivates
the
solution
of
the
repairing
network.
This
this
spiral
and
network
is
often
ip
based
next
one,
please.
H
This
does
corrobor
describe
the
deterministic
requirement
in
lg
very
network.
The
uric
is
one
of
the
key
aspects
in
4g.
It
is
a
requirement
so
that
the
transport
network
mentioned
in
the
last
page
and
also
I
need
to
provide
low
latency
service.
However,
it
is
very
hard
for
the
repairing
and
to
provide
a
deterministic
service,
because
the
traditional
heat
network
are
based
on
static,
statistical
multiplexing
and
cannot
can
only
provide
the
ef
service.
H
This
style
is
about
the
related
works
in
algebra
e
and
itf.
Asm
task
group
has
contained
many
projects
for
providing
a
deterministic
service
us
through
the
so2
networks.
H
There
are
some
characteristics
about
it
and
the
idea
of
that
networking
group
also
have
done
a
lot
of
jobs
to
enable
this
deterministic
it
to
operate
over
there
to
our
layer
three
segment.
However,
the
tenet
now
is
supposed
to
working
to
work
in
campus-wide
networks
and
private
ones,
and
not
power.
The
very,
very
large
scale,
asp
network
scenario.
H
D
Yeah
you
say
that
it's
that
net
is
targeted
for
campus.
I'm
not
sure.
We've
seen
that
the
scope
certainly
signal
administrative
domain
is
our
scope,
it
doesn't.
The
single
administrative
domain
could
be
small,
it
could
be
very
large,
so
I'm
not
sure
what
comment
you're
making
there
and
I
don't
think.
H
To
the
base
of
my
understanding,
perhaps
some
misunderstanding
here,
but
I
think
the
the
teasing
mechanism
is
not
designed
for
a
large
scale
as
his
network.
Is
it
okay.
H
D
A
Yeah,
I
fully
agree
with
with
lou
actually
that
our
charter
says
significant
word
by
word:
single
administrator
controller
within
a
closed
loop
of
administrative
control,
and
I
think
an
isp
network
is
absolutely
in
scope
of
that.
Not
so,
there
may
be
misunderstanding
in
the
charter.
Campus
is
just
an
example,
but
I
think
it
is
in
scope
of
that,
but
yeah
that's
discussed
on
the
on
the
list
further
or
clarify
this
later.
So,
okay.
H
This
at
this
page,
we
show
some
gaps
for
large
scale,
layer,
3
feminist
network.
Currently
we
are
short
of
a
common
and
a
neutral
mechanism
that
can
provide
deterministic
transport
in
fairly
barren
network,
and
that
is
used
we
craft
for
this
large-scale
deadness.
H
H
H
H
This
page
will
show
some
reason
why
nc
mechanism
cannot
be
directly
used
in
large-scale
layer,
3
network.
The
first
one
is
some
testing
mechanisms
need
a
secondation
or
network
equipment
which
is
hard
in
large
network.
H
Please
see
that
it
brings
in
some
complex
maintenance
jobs
across
a
large
distance.
The
jobs
are
not
needed
before,
and
the
second
is
comparison
mechanism
in
the
per
flow
state
in
the
food
implant
which
is
unscalable.
The
third
is
that
marketing
the
tsm
mechanism
is
a
constant
and
a
foreseeable
traffic
characteristic.
H
H
When
we
are
seeking
the
problem
in
current
epi
voting
mechanism,
we
find
that
the
main
problem
is
that
in
the
current
network,
a
long
delay
in
doing
or
unpackaged
losses
due
to
us
are
accessible,
but
is
unacceptable
in
the
deterministic
forwarding
even
be
given
a
higher
priority.
A
packet
can
experience
a
long,
investing
rate
of
loss
in
a
relatively
light
loaded
network
because
of
the
problem
of
microburst.
H
The
map
force
is
a
special
case
of
network
congestion,
which
typically
lasts
a
long,
a
short
period
at
the
graduality
or
in
the
microwave
brush.
A
lot
of
data
are
received
on
the
interface
suddenly,
and
the
tempered
requirement
would
be
tens
or
hundreds
of
the
average
randomized
requirement,
or
even
you
see
the
interface
spanners
next
phase.
Please.
H
It's
a
video
about
the
introduction
of
the
microbots
on
the
left
finger.
We
can
see
that
if
we
observe
the
traffic
utilization
benefit
on
the
interface
at
the
gradual
granularity
of
per
second,
a
small
scroll
may
be
obtained,
but
we,
when
we
observe
the
traffic
utilization
fundamental
under
the
graduality
of
a
millisecond,
we
can
see
microbrews
on
the
interface.
In
most
cases,
the
brushed
the
buffer
on
the
equipment
can
handle
the
microburst,
however,
but
in
some
corner
case
microbursts
bring
in
a
long
delay
or
even
loss.
H
H
Definitely
ep
network
has
a
flexible
topology
which,
where
the
incoming
traffic
may
exceed
the
benefit
of
the
out
of
screen
interface,
for
example,
an
interface
with
a
large
bandwidth
may
need
to
send
traffic
to
a
interface
with
a
small
bandwidth
or
multiple
flows
from
error.
Incoming
interface
may
need
to
occupy
the
same
outgoing
interface.
H
Finally,
the
ip
nodes
have
been
designed
to
send
traffic
as
quick
as
possible,
and
it's
not
where
whether
the
down
load,
the
downstream
nodes
traffic
can
handle
the
traffic.
For
example,
we
show
a
finger
here
before
the
scheduling
in
ap
network
the
package
available,
but
after
scheduling
the
packet
will
be
gathered,
even
the
total
traffic
rate
is
on
trend
next
page.
Please.
H
H
Our
draft
proposed
a
mechanism
the
same
magnum,
including
the
in
the
pd
node,
do
the
flow
shipping
and
the
color
of
the
deterministic
traffic
and,
in
the
keynote
recognize
the
feministic
under
for
interface
shipping.
So
it's
more
easier
for
the
network
equipment
to
upgrade
it.
The
purpose
is
to
maintain
a
proper
buffer
depth
on
the
p
node
and
forward
the
deterministic
orderly,
instead
of
as
long
as
possible,
as
in
the
current
ip
forwarding.
H
Our
first
job
includes.
First,
we
need,
for.
We
need
a
mechanism
in
control
plan
to
guarantee
the
total
benefits
on
the
interface
node
is
not
exceeded.
Secondly,
we
need
a
convenience
way
to
for
the
service
to
inform
the
network
about
the
bandwidth
they
needed
they
need.
Suddenly,
the
deterministic
traffic
should
be
colored
so
that
the
keynote
can
recognize
them
next
page.
Please.
I
H
I
think,
in
our
understanding
that
the
tsm
mechanism
perhaps
can
handle
the
microburst
problem,
but
at
a
relatively
higher
cost
and
our
purpose
is
to
increase
microbursts
at
a
lower
cost.
That's
some
simple
idea
to
closer
load.
It
is
a
perfect
transport.
H
D
We
are
actually
gonna
running
a
little
late,
so
thank
you
very
much
for
this
there's
a
lot
more
in
this
presentation
than
that's
actually
in
the
draft.
So
we
we
look
forward
to
the
the
next
version,
which
may
have
some
more
details
in
it.
Also,
I
think
you
might
be
looking
for
an
informational
document
than
a
standards
track,
because
standards
track
is
all
about
defining
either
protocol
extensions
or
specific
mechanisms.
B
Okay,
okay,
hello,
I'm
greg
mursky
and
I'm
presenting
this
work.
On
behalf
of
the
group
of
the
offers
we
had
a
discussion
of
their
document
that
was
this
presented
in
a
reliable
wireless
raw
working
group
and
agreed
that
we'll
work
on
new
document
to
be
discussed
and
worked
in
that
net.
B
That
will
be
a
common
oem
features
that
are
common
for
that
net
and
the
raw
and
the
document
that
will
be
continuing
working
in
the
world
working
group
will
concentrate
on
this
technical,
technological,
specifics
of
wireless
and
oem
in
the
wireless
reliable
network.
Our
next
slide,
please.
B
So
the
structure
is
document
pretty
standard
and
it
includes
their
terminology.
Oem
methods
are
classified
and
characterized
based
on
rfc
7799,
which
kind
of
is
active
passive
and
in
between.
B
We
use
in
this
first
version
terms
like
map
and
mip.
It's
maintenance,
endpoint
and
maintenance
entity.
Intermediate
point:
these
are
not
often
used
at
itf.
I
can
only
point
probably
for
one
technology
where
we
use
them,
but
they're
more
often
used
in
other
sdos.
B
So
I
would
like
you
to
think
and
comment
whether
we
can.
We
should
switch
to
other
terms
like
endpoint
and
intermediate
point
or
transit
node,
and
then
we
have
sections
that
look
in
aspects
of
oem
for
operation,
administration
and
maintenance.
Actually
that's
what
the
acronym
oem
stands
for
next
slide.
Please.
B
So
operation,
what
is
objective
operation?
It's
a
keep
network
up
and
running
and
have
fault
management
and
performance
monitoring
information
collection.
It's
a
passive
measurement
method
according
to
77.99
and
examples
could
be
using
snmp
based
on
the
map
or
yang
data
model
notifications
or
grpc.
B
Usually
it
works
out
of
band
comparing
to
their
monitored
floor
or
it
could
be
in-band.
Definitely
out
of
band
is
a
more
conservative
approach,
though
out
of
band
probably
is
a
lower
guarantee
of
collecting
the
data
or
not
losing
the
data.
Continuity
check.
B
As
you
see,
we
differentiate
between
two
functions
on
the
fault
management.
The
continuity
check
is
usually
is
concern
of
the
continuity
of
the
path
so
which,
if
we
take
an
algae
for
electricity,
it's
that
well,
there
is
a
wire
that
connects
point.
A
and
b.
B
B
Another
function
in
fault
management
is
a
connectivity
verification
and,
if
continue
using,
this.
B
Analogy
from
called
wiring
is
that
we
have
a
specific
wire
that
connects
point
a
and
b,
for
example,
red,
and
we
don't
receive
the
electrons
that
travel
on
a
blue.
B
Then
one
important
operational
function
is
a
route
tracing.
It's
a
icmp
echo
request,
known
as
a
trace
route
fault.
Detection.
Localization
are
very
important
and
one
very
important
thing
that
we
need
to
stress
and
remember
when
we
discuss
and
consider
oem
active
oem.
The
test
packets
must
always
be
in
band,
because,
if
active,
oem
packets
are
not
in
band
that
default
detected
or
performance
measured
are
not
applicable
to
the
flow
that
we
monitor
next
slide.
Please.
B
So
the
objective
of
administration
functions
are
keeping
track
of
resources
and
how
they
use
that
include
the
telemetry
information
and
telemetry
information
is
something
that
is
measurable
or
it's
a
network
state
information,
for
example,
buffer
occupancy
queuing
delay
residence
time.
B
It's
very
important
to
use
metrics
that
are
additive
that
characterize
the
node,
but
then
can
be
combined
to
characterize
end-to-end
metrics
measuring
end-to-end
metrics
might
not
be
useful
and
sometimes
may
be
misleading.
Next.
B
So
again,
it's
important
to
collect
telemetry
information,
enable
network
state
condition,
evaluation
and
collection
methods
might
have
impact
on
the
network
resources
because
again,
as
was
mentioned
in
a
second
slide-
that
if
the
telemetry
collection
uses
is
in
banned
that
it
takes
their
available
bandwidth
from
the
service
and
next
step
discussion.
B
So
we'll
have
the
document
for
sections
at
least
common
oem
requirements
include
section
applicability
of
hybrid
oem
in
a
deadnet
and
hybrid.
It's
a
methods
that
combine
passive
and
active,
and
we
always
welcome
common
suggestions
contributions
and
want
to
ask
to
consider
a
working
group
adoption.
Thank
you.
A
Okay,
thank
you.
Thank
you
very
much
for
the
presentation.
We
have
two
people
in
the
queue
baraj
first.
I
A
Okay
good
point,
so
please
fill
in
your
show
of
hands
it's
next
to
the
chat
window
in
mytaco.
While
we
are
discussing
the
questions.
I
Okay,
so
just
two
comments.
I
was
very
happy
about
your
proposal
on
the
terminology
to
use
the
maps
and
meeps,
so
I
am
supporting
to
to
have
that
the
terminology
and
the
discussion
regarding
that
net
oem
framework.
I
The
the
second
comment
is
also
related
to
that
that
I
think
what
I
miss
still
a
little
bit
from
this
document,
which
is
providing
a
very
good
basis
for
the
oem
framework,
is
that
we
have
in
that
net
defined
two
sub
layers,
the
service
and
the
forwarding
sub
layer,
and
I
think
it
would
be
great
to
have
also
some
thoughts
about
where
to
place
these
maps
and
meeps
regarding
those
that
net
sub
layers.
E
B
Their
idea
is
that
the
raw
document
will
be
concentrating
on
raw
specific
and
then
referencing.
This
document
for
more
general
aspects
of
oem
framework,
because,
as
we
discussed
and
agreed
that
the
death
net
is
less
technology,.
B
Exposed
so
it's
a
better
place
to
have
the
framework
for
common
oem
and
then
have
some
specifics
of
oem
in
the
wireless
technology,
because
there
are
specifics
and
their
balance
between
what
is
inbent
and
out
of
band
would
be
different.
If
we
talk
about
wireless
wireline
networks,.
A
A
I'm
sorry
so
and
david,
but
we
are
over
time
and
we
had
a
good
number
of
people
who
read
the
draft.
Please
please
read
the
draft
and
continue
the
discussion
on
the
on
the
list.
D
Yeah
and
to
both
sue
and
david,
you
can
send
your
comments
to
the
list,
particularly
if
you
would
object
to
adoption.
That
would
be
really
helpful.
So
sorry,
for
the
short
time
we
only
have
any
more
for
the
session.
G
Okay,
thanks
hi,
this
is
doug
crosston.
This
is
a
new
traffic
that
we've
submitted
to
the
to
the
working
group
just
recently,
I'm
presenting
on
on
behalf
of
my
courses,
france
and
you're
from
siemens.
If
you
can
go
to
the
next
slide,
please
so
we
the
slide,
focuses
on
the
control
plane,
signaling
in
accordance
with
the
control
plane
framework
that
we
are
referencing
in
the
in
the
draft
as
well.
G
At
the
moment,
we
are
targeting
to
cover
the
distributed,
centralized
and
hybrid
signaling
scenarios
that
are
outlined
in
the
control
plane
framework,
but
we've
focused
so
far
on
the
on
the
on
on
the
distributed
part.
Yesterday,
I'm
trying
to
keep
my
time
down
they
they.
What
we
intend
to
do
is
particularly
solicit
feedback.
That's
the
whole
point
of
presenting
here.
So
the
main
focus
of
the
work
at
the
moment
is
section.
G
Two
in
case
you
haven't,
read
it
the
main
proposal
for
aligning
layer,
2
and
layer,
3
signaling,
which
I
will
have
a
slide
on
later
on,
which
is
the
part
where
we
are
soliciting
feedback
is
in
2.5
for
you,
as
a
navigation
and
section
3
and
4
might
be
for
future
work,
so
the
baseline,
as
mentioned
yeah
next
slide.
Please
thank
you
is
that
we
cover
the
three
cases
it's
distributed,
being
the
focus
on
after
draft
the
other
ones
for
potential
other
contributors
or
from
us
to
be
filled
in.
G
So
the
the
draft
starts
with
discussing
the
main
difference
between
rap
as
an
example
for
tsn
and
rsvp.
G
We
we
start
by
asking
a
number
of
challenges
in
section
2.2
and
the
foremost
if
rcp
insert,
is
the
right
starting
point
for
the
alignment
which
we
then
come
back
later
in
2.5
and
then
how
to
effectively
address
those
various
issues
that
are
discussed
in
2.4
and
also
what's
the
nature
of
the
interface
between
rsvp
and
rap
in
the
scenario.
So
next
slide
please.
G
So
this
is
the
the
interactions
that
we
outlined
in
figure
2
of
the
12.
This
is
a
slightly
prettier,
looking
version
of
it,
where
we
have
the
assumption
of
a
a
bridge
scenario
here
from
an
end
system
over
a
first
router
to
another
end
system
on
the
right
hand,
side
that
we
left
out
here,
that's
included
in
figure
two.
G
The
main
interface
that
we're
discussing
the
draft
is
is
obviously
focus
on
the
layer,
three
control
plane-
and
we
mentioned
the
tsn
api
in
in
section
2.6
as
an
example,
and
that
you
know
that
that
can
be
used.
And
so
the
focus
is
on
the
du
api
and
the
dl
api.
That's
shown
here
in
the
figure
the
next
slide,
please.
G
So
what
we're
proposing,
which
is
what
we're
seeking
feedback
from
the
working
group,
is
the
rationale
of
the
the
introduction
of
what
we
call
rsv
rsvp.net,
the
rationale
to
split
the
control
over
the
resource
style
and
the
sender
selection
that
would
align
rsvp
to
the
announce
model
of
rap
where
the
resource
style
is
actually
known
when
propagating
the
announce
downstream.
So
it
aligns
the
model
used
in
in
in
networks
like
tsn,
better
with
the
the
the
cycling
you
would
do
yeah
on
layer.
G
Three,
that's
the
first
part
that
is
being
discussed
in
the
in
the
proposal
for
rsvp.net.
The
second
part
is
also
to
introduce
a
another
resource
style,
the
so-called
coordinated
shared
resource,
which
would
support
a
large
amount
of
deterministic
connections
with
a
small
data
usage.
Instead
of
using
scheduling
all
of
these
connections
into
a
shared
resource,
that's
one
of
the
the
other
part
that
we
are
we
are
discussing
in
that
proposal.
G
G
The
future
plans,
that
is
an
initial
draft
this
is,
has
been
brought
up
specifically
to
solicit
feedback
on
the
proposed
changes
to
the
signaling
and
rsvp,
given
that
there
are
also
discussions
on
and
then
work
on,
rap
going
on
ongoing
and
I
triple
e,
and
in
particular,
urgent
and
and
friends,
are
very
involved
in
the
ieee
work
as
well.
G
G
Second
plan
is
also
to
to
outline
and
revise
the
dtu
api
to
make
it
independent
of
the
particular
model
of
signaling
distributed,
centralized
and
also
add
the
missing
version
for
centralized
and
hybrid
if
the
material
and
we
find
core
contributors
as
well
foremost,
apart
from
the
feedback.
Obviously,
we
solicit
also
and
welcome
co-authors
and
contributors
to
the
discussion
from
the
melinx.
Thank
you
very
much.
A
Thank
you
very
much
for
the
for
the
contribution
and
the
presentation.
As
we
are
running
out
of
time,
I
would
suggest
a
discussion
on
the
list.
So
please
put
your
question
and
comments.
Please
read
the
draft
and
and
and
discuss
it
on
the
list.
So
let's,
let's
move
to
the
next
and
the
last
presentation
to
have
some
time
for
it.
D
Is
there's
some
suggestion
to
have
an
interim
so
that
we
can
have
more
time
particularly
to
discuss
new
material?
I
think
that's
a
very
good
idea,
but
we'll
try
to
schedule
something
right,
we'll
discuss
it
offline
and
probably
try
to
schedule
something
in
december.
So
thank
you
for
that
suggestion.
J
Oh
okay,
this
is
funny
from
huawei.
This
will
be
a
very
good.
The
draft's
name
is
the
segment
routine
for
the
redundancy
protection
next
place
yeah.
Actually
we
have
already
introduced
this
one
to
then
that
for
several
meetings,
so
this
this
is
only
the
the
plan
that
we
are
going
to
notice
the
that
networking
group.
Maybe
next,
please.
J
Yeah
we
take
this
service
protection
function
and
and
from
these
three
techniques,
three
data
techniques.
So
we
rename
it
as
the
agenda
as
the
redundancy
protection
as
a
generalized
service
protection
solution.
J
So
we
propose
a
new
draft
to
spring
working
group
and
to
define
the
the
the
segment
and
also
the
the
other
information
like
the
metadata
and
redundancy
policy.
In
this
new
draft.
We
we
may
expect
more.
The
other
extension
works
in
the
spring
and
the
six
month
work
groups.
So
as
what
we
have,
we
get
the
comments
from
from
the
networking
group
chairs.
So
we
did
this.
Did
this
work
and
we
like
to
inform
the
then
that
and
collect
the
feedback
from
the
chairs
and
also
the
working
group
yeah?
A
I
would
like
to
mention
that
we
started
to
coordinate
with
the
sprint
chairs,
like
I
mean
that
matures
and
spring
chairs
on
the
topic-
and
it
was
discussed
that
last
itf
when
it
was
presented
by.
C
A
That
this
should
happen.
We
started
to
doing
that,
and-
and
this
work
you
should
be
coordinating
between
the
two
groups
spring-
is
the
home
for
for
for.
A
J
Yeah:
okay,
we'll
keep
this.
This
work
between
the
two
groups
working
books.
A
A
Ahead:
okay,
we
are
over
time
a
little
bit,
so
we
need
to
close
the
session.
Thank
you
very
much
for
all
the
contributions
and
as
we
discussed,
let's,
let's
continue
the
discussions
on
the
list
and
we
will
work
on
on
on
an
interim
and
then
discuss
how
to
how
to
do
that
or
how
to
progress
with
with
all
these
new
work
items.