►
From YouTube: IETF101-CCAMP-20180319-1740
Description
CCAMP meeting session at IETF101
2018/03/19 1740
https://datatracker.ietf.org/meeting/101/proceedings/
B
D
A
C
D
G
A
G
H
D
D
D
J
A
K
J
I
L
J
C
M
E
I
A
E
D
D
A
D
G
J
A
E
A
A
D
H
C
A
H
C
C
C
We
will
try
to
be
a
little
bit
quicker
than
than
expected
so
dizzy.
Welcome
to
this
joint
meeting
between
see
camper
and
money,
I
hope
that
was
the
right
transition
for
people
from
money
that
not
don't
know
ASSA.
My
name
is
Daniela
chica
le
I'm,
one
of
the
co-chairs
of
op
C
camper
Fatah,
please
stand
up.
Apatite
is
the
other
co-chair.
You
want
you
to
introduce
yourself
sure.
C
C
For
today
we
will
three
presentations,
an
introduction
on
the
dilib
protocol,
Stan
just
in
arica,
and
then
we
will
have
two
presentations,
one
from
loop
on
de
leopard
if
server,
where
a
create
window
and
control
plane
based
pose
extensions
and
then
one
presented
by
Rica
on
the
possibility
of
moving
traffic
class
ID
to
a
new
draft.
So
let's
move
fast.
B
Rick,
Taylor
and
I
are
going
to
kind
of
double-team
this
presentation,
the
first
slide
kind
of
says
it
all
develop.
What
is
it
and
why
do
I
care
about
it?
We
think
it's
got
applicability
for
control
and
monitoring.
It
was
specifically
designed
to
control
and
monitor
RF
devices.
Radios
could
also
have
applicability
in
microwave
environments
and
then
even
in
some
wired
environments,
there's
been
talk
of
of
using
delay
and
apparently
at
the
last
meeting
in
Singapore.
There
was
question
of
why
isn't
this
a
sea
camp?
R
Is
actually
presentation,
I
did
in
the
routing
area,
I've
been
meeting
in
Singapore,
so
I'm
going
to
blast
through
this
pretty
quickly,
because
this
is
the
second
time
these
slides
been
out,
but
it's
more
a
case
for
their
seachem
guys,
who
don't
really
know
what
delay
pays
so
quick
blast
through,
so
it's
LMP
according
to
blueburger,
there
we
go
okay,
so
Dilip
has
come
out
of
the
mani
working
group.
It's
now
we're
trying
to
reach
out
beyond
that.
It's.
R
How
do
you
do
routing
in
dynamic
networks
when
everything
moves
around
really
quickly
and
your
link?
There
is
based
probably
on
radio
devices
where
the
links
go
up
and
down
and
so
on.
How
do
we?
How
do
we
solve
the
problem
of
making
routing
work?
Well
in
these
environments?
First
off?
How
do
I
form
an
adjacency
seems
like
a
really
obvious
question:
you
do
the
usual
layer,
three
staff
send
some
hello,
packets,
yeah
you're
there.
How
do
you
maintain
that
adjacency?
Well,
you
sent
some
keeper
lives,
that's
cool
yeah.
R
Okay,
so
a
little
bit
of
a
digression
here,
IP
has
one
you
know
we're
just
using
IP
over
link.
There's
in
all
works.
Great
radio
vendors
are
now
moving
to
supporting
IP
across
their
networks.
They
do
this
using
clever
stuff
to
carry
them
on
their
bottom
end
layers,
but
fundamentally
they're
designed
to
carry
IP
and
they
differentiate
by
doing
clever
stuff
to
move
the
IP
around,
but
fundamentally
they
present
an
IP
interface
back
to
your
land
and
the
clever
radio.
When
does
it's
special
source?
R
Okay,
and
from
a
dealer
perspective,
when
we're
talking
about
radios,
we're
not
talking
about
your
traditional
point-to-point
stuff,
we're
all
talking
SATCOM
systems,
we're
talking
these
exciting
meshing,
radio
systems
that
are
very
popular
in
when
you
start
talking
about
many.
A
lot
of
radio
vendors
will
turn
up
and
say:
hey.
We
do
a
cool
man,
a
system
that
you
know
solves
the
hidden
terminal
problem
and
does
all
sort
of
cool
stuff
and
also
freespace
optical
and
microwave,
and
that
kind
of
stuff.
R
So
this
is
the
key
proposition
for
Neela.
This
is
kind
of
one
of
the
takeaway
points
which
is
I'm,
gonna,
read
it
out.
So
when
dealing
with
links
more
complicated
than
wires,
the
link
layer
is
already
doing
discovery
and
maintenance.
So
why
are
we
doing
it
again
at
the
routing
layer,
we're
just
wasting
time
and
effort?
R
Dilip
is
a
simple
protocol
that
runs
between
your
Rooter
and
its
locally
attached,
radio,
which
we
refer
to
as
a
modem
to
allow
the
radio
to
tell
the
attached
router
when
other
nodes
that
are
reachable
across
its
over-the-air
interface
are
reachable
so
when
they
arrive
and
depart
including
link
their
information.
So
there
are
defined,
uniquely
by
MAC,
address
we're
assuming
a
common
layer
domain.
You
can
include
IP
address
information,
because
that
saves
you
having
to
ARP
and
also
its
supports
multicast.
So
if
you've
got
multi
car
support,
that's
fine!
It's
they're!
R
Equally,
not
only
telling
you
when
destinations,
arrive
and
depart.
It
will
also
tell
you,
when
the
quality
of
a
link
to
those
destinations
changes.
So
if
you've
got
to
radio
route
repairs
moving
away
from
each
other,
the
deal
at
protocol
will
tell
each
attached
Rooter
of
those
pairs,
that
the
link
is
getting
worse
I'm,
making
the
assumption
it
gets
worse
as
they
drive
apart,
and
vice
versa.
As
they
come
closer
together.
Hey
my
link
is
getting
better.
R
Okay.
So
how
does
this
help
well
by
listening
to
if
I'm
gonna
read
it
out
again,
because
it's
a
good
slide,
I?
Think
by
listening
to
events
from
the
link
layer,
routing
protocols
can
react
to
the
arrival
and
departure
of
peers
in
a
much
more
timely
fashion
than
having
to
poll
so
we're
trying
to
move
to
event-driven
routing
adjacencies
and
also,
if
you
have
some
idea
of
the
quality
of
links,
you
can
make
far
more
intelligent
decisions
about.
R
How
long
should
my
timers
be?
What
sort
of
cost
functions
that
I
can
apply
to
these
links?
You
know
you
can
start
to
play
some
interesting
games
around
link,
state
routing
and
that
kind
of
stuff.
Okay,
so
I
work
forever.
We
make
aircraft
primarily,
but
we
also
make
networks
aircraft
flying
over
a
fixed
ground
position.
It
can
take
45
seconds
to
go
from
Horizon
to
Horizon.
Now
it
would
be
quite
nice
if
we
could
offload
some
of
the
data
off
the
aircraft
or
perhaps
upload
some
new
data
onto
that
aircraft.
R
Okay,
so
we've
got
45
seconds
to
do
this,
including
both
peers,
noticing
each
other.
The
link
layer,
synchronizing
IP
layer,
sorting
out
addressing
then
top
level
applications
get
around
to
actually
moving
the
data,
so
that
that
takes
a
very
long
time
if
you're,
relying
on
all
these
timeouts
and
so
on
so
trying
to
break
it
down.
Ospf
hello
time
is
commonly
10
seconds
so
you're
starting
to
cut
into
the
amount
of
usable
transmission,
no
data
transmission
time
you've
got
and
at
a
point
here
is
particularly
when
you
start
to
play
around
in
these
radio
systems.
R
You'll
find
a
lot
of
application.
Developers
have
tested
this
on
their
land
in
the
office,
and
you
know
100
megabit
Ethernet,
it
always
great.
You
then
run
it
over
a
nineteen
point,
two
K
modem.
It
rarely
works
well,
but
that's
a
slightly
different
issue,
but
it
applies
to
routing
protocols
as
well
as
to
the
top
level
application
stuff.
R
Yet,
with
the
radio
system,
you
can
hand
tune
all
your
parameters
to
make
them
nice
and
fast
I've.
You
know
for
donkey's
years
people
have
been
rolling
out
OSPF
for
radio
networks
and
they
spend
an
awful
lot
I'm
standing
in
a
wet
field,
tweaking
config
options
and
eventually
it
works,
but
it
only
works
in
that
scenario
and
as
soon
as
you
move
them,
you've
got
a
stark
whole
process.
Again,
it's
painful.
A
little
point
in
here
is
that
Sdn
sometimes
seems
to
make
it
all
worse.
Every
time
I've
tried
this
with
Sdn.
R
R
So
this,
for
all
you
guys
who
are
really
interested
in
Sdn
SDM
in
in
mobile
ad
hoc
networks
or
networks
with
radios
and
dodgy
links,
is
a
really
interesting
subject
and
I
don't
have
the
answers,
but
if
anyone
does
have
the
answer,
please
tell
me
because
I
think
there's
something
there,
but
that's
that's
a
side
issue.
Key
point
to
that
slide
is
the
end
user.
Just
wants
to
do
is
day
job.
R
You
know
the
poor
guy
who
sat
in
that
vehicle
with
that
radio
PMO
you
know,
paramedic
or
or
whatever
he
doesn't
want
to
mess
around,
spend
his
time.
Rebooting
the
router
and
fiddling
around
with
the
comms
equipment
he
wants
to
get
on
saving
lives
or
whatever
so
using
deal
app.
We
should
be
able
to
skip
our
paying.
We
should
be
able
to
do
better
write
better
things
with
the
intervals.
I
know
I'm
going
very
quickly.
These
slides
are
out
there.
We
can.
We
can
basically
short-circuits
some
of
the
stuff.
R
We
have
to
estimate
upfront
and
actually
take
metrics
from
the
link
layer.
Yeah,
that's
very
cool,
but
it
sounds
like
this
only
really
makes
sense
in
the
radio
world.
Well,
I'm
not
sure
it
doesn't,
because
link
layers
have
got
really
complicated.
These
data's,
we
well
know
you
know
you're
starting
to
tunnel
there
to
staff
there's
loads
with
virtual
networking
LTE.
You
know
that
things
in
clever
radio
stuff
Wi-Fi.
R
R
Whenever
it
rains,
I,
don't
know
it's
something
to
do
with
the
pipe
work,
but
these
things
you
know
moving
link
layers
happen
beyond
the
world
of
radios
and
having
the
routing
and
the
higher
layers
understand
that
the
link
layer
can
perform
differently
and
getting
that
feedback
back
from
the
link
layer
is
a
powerful
concept,
so
this
is
what's
happening
next.
Indeed,
up
I
won't
cover
this
because
we're
doing
a
couple
of
presentations
on
it.
R
S
Justin
Dean
chair
them
anywhere
I
just
wanted
to
point
out
that
some
vendors
have
been
adopting
this
and
I
know.
Multiple
radio
vendors
that
have
put
this
in
radios
I
know
that
there
are
a
couple
router
companies
that
have
started
to
put
this
into
the
router.
So
it
is
something
that's
being
adopted
and
moving
forward
within
the
community.
Absolutely.
R
You
know
I'll,
second,
that
by
the
fact,
I've
spent
a
lot
of
the
last
18
months
on
the
phone,
radio,
vendors
and
router
vendors,
who
want
to
know
how
to
implement
this
and
it's
being
specified
as
part
of
big
governmental
projects
and
so
on.
As
this
is
the
way
people
see
going
forwards,
particularly
for
the
fuzzy
edge
of
the
network,
you
know.
T
Okay,
sorry
only
stuff
at
that
zone,
so
at
the
co-chair
of
seachem
I'm,
really
happy
to
see
that
you
guys
bring
this
kind
of
dinner
to
see
camp
for
discussion.
So
looking
at
Indian
lab
I
think
actually
are
it's
a
kind
of
protocol
to
exchange
information
between
two
ends
of
a
link
so
which
it's
quite
a
similar
to
LNP
defined
in,
say
camp
because
you
know
the
MMP
protocol
can
also
be
used
to
exchange
information
between
a
pair
of
loads.
T
But
actually
there
are
also
are
some
difference
between
these
two
protocols.
So
first
I
think
you
know
arm
in
lab.
It's
you
only
use
the
for
one
thing:
go
or
hop.
You
know
session
right
and
and
order.
You
know,
Dean
Dean
up
signals
are
run
over
TCP,
but
for
the
NP
NP
messages
are
run
over
UDP.
So
this
our
difference.
The
second
one
is
Grantham
NP.
It's
called
link
management
protocol,
so
it
can
be
used
not
only
for
link
exchange
information,
but
also
it
can
be
used
for
managing
key
links.
T
R
U
So
it
was
more
from
that
perspective.
From
the
te
perspective
now
it
so
happens.
One
of
the
things
that
deal
F
does
is
it
gives
you
metrics
to
the
destinations,
so
you
actually
get
a
whole
set
of
parameters
to
every
one
of
these
endpoints
and
while
that's
not
quite
the
normal
te
way
of
looking
at
it.
Well,
we
understand
getting
resource
availability
to
ports.
Lambdas
that
may
have
different
different
bandwidth,
availability,
different
qualities
and-
and
so
there
actually
is
some
similarity
there.
U
B
In
in
terms
of
the
parameters
that
can
be
carried
right
now,
what
we
have
specified
is
data
rates
both
in
terms
of
the
maximum
data
rate
of
the
modem
can
deliver
and
the
current
data
rate
or
what
he's
doing
right
now
a
view
on
latency,
that's
on
the
link,
and
then
there
was
a
there
is
an
arbitrary
and
capricious
parameter
that
was
inserted
because
there's
radio
magic
going
on
that.
We
don't
know
about
that.
Most
of
the
vendors
say:
I
tell
you,
but
I'd
have
to
kill
you
I,
don't
want
to
know.
B
We
call
it
radio
link
the
radio
link,
quality
or
rlq.
So
it's
an
abstraction
of
how
well
the
link
is
or
isn't
working.
It's
viewed
as
a
it's
not
supposed
to
be
looked
at
as
a
percentage
value,
but
it
really
is.
It
runs
0
to
100
where
zero
is
the
worst
link.
You've
ever
seen
and
100
is
the
best
link
you've
ever
seen
now.
That
being
said,
we're
going
through
a
process
right
now
with
a
couple
of
drafts
where
we're
adding
tlvs
and
adding
additional
data
points,
and
so
you.
R
Missed
two
one
of
the
metric
we've
got
is
another
blanket
one
called
resources
could
be
battery
power.
It
could
be
how
much
work
is
this
unit
doing.
Sometimes
people
want
to
route
away
from
the
battery
powered
things
on
the
ground,
so
they're
more
likely
to
die
than
the
things
on
mains
electricity,
it's
a
sort
of
catch-all
one
and
the
other
one,
the
one
that
went
in
quite
late,
but
was
proven
to
be
really
popular
as
an
ability
to
say
what
the
MTU
is.
So
it
saves
you
having
to
do
PMT.
L
V
This
is
a
deborah,
I'm
ad,
for
this
again
I
would
tell
C
camp.
Don't
get
hung
up.
You
know
with
that.
Your
tour
currently
says
to
eat
protocols,
as
we
are
seen,
everybody
always
in
the
end
wants
to
do
te.
There's
always
something
that
comes
along
and
so
I
would
look
at
this
more.
Are
you
interested
in
this
work
and
then
we'll
figure
out
your
charter
later
yeah
as.
C
W
Thank
you
Amy
from
Huawei,
so
this
is
my
second
time
to
hear
about
this
presentation
that
I
have
maybe
a
deeper
understanding,
I
hope.
It's
Critias
have
several
comments.
The
first
one
I'm
many
working
for
microwaving,
it's
also
radio,
but
it
is
true
that
is
the
radio
we
have
the
common
narrative
example.
The
bandwidth
will
change
according
to
the
environment.
W
That's
the
thing,
but
I
see
the
requirements
are
quite
different
because
in
our
case
we
are
working
for
mobile
back
home
many
in
the
10-count,
so
the
device
are
fixed,
it's
not
moved
in,
and
so
we
don't
have
a
such
requirements
to.
You
know,
for
example,
to
have
a
faster
discovery
in
our
court
short
time
and
then
the
second
comments
I
would
like
to
make
is
about.
W
One
can
of
the
radio
feature
should
be
supported
other
than
the
radio
actually,
in
our
case
sense
we're
in
the
telecom
network.
We're
asked
by
the
operators
to
support
the
current
popular
protocols,
for
example
the
Netcom,
or
something
like
that
and
so
I
see
also
as
a
pink.
We
have
a
similar
feature,
but
requires
active
branch
and
I
was
wrong.
To
make
another
example
about,
we
also
have
protocol
to
exchange
about
the
radio
band
wise
in
idea
with
define,
there's
a
definition.
W
Isn't
it
Oh
him
I?
Think
a
Greg
make
this
comment
saying
I
started
meeting
the
ban
was
a
notification
message:
it's
defined
used
the
internet,
om
to
exchange
the
radio
Benoist
and
it's
grunting
corrode
the
nominal
bandwidth
and
is
a
current
of
bandwidth,
but
it's
Tony
man
wise
and
it's
widely
supported
by
the
ocarina
microwave
vendors.
It's
we
use
a
lot.
So
that's
several
comments.
Helped
abetted
to
make.
Thank
you
just.
R
In
response
to
your
last
comment,
that's
great
because
if
the
link
there
is
already
running
these
protocols
defined
by
standards
bodies,
that's
great.
That
means
that
information
to
just
be
reflected
up
to
attached
reuters.
So
it's
I
think
these
are
all
compatible
rather
than
competing
protocols.
Yeah.
W
X
B
I
read
it
over
I
will
say
when,
when
we
define
deal
app,
we
tried
to
be
very
careful
about
saying
we're
going
to
we're
going
to
strictly
define,
from
from
a
protocol
perspective,
what
data
traverses
the
link,
but
we're
going
to
stay
completely
away
from
what
you
would
do
with
that.
Now.
In
point
of
fact,
the
DLF
implementations
that
I've
seen
there's
signaling
the
Misti.
Let
process
picks
up
this
data
and
then
signals
layer
3
to
go
the
right
thing
like,
for
instance,
on
presentation
of
a
new
radio,
a
new
neighbor.
B
X
C
A
second
Thank
You
pinger
we
started
at
20
minutes
late.
We
would
run
at
10
minutes
late.
If
you
I'm
talking
to
the
two
managers
agree.
I
would
like
to
give
more
time
to
this
discussion,
because
I
think
it's
more
important
or
two
I
yes
discuss
about
these
are
and
maybe
postpone
of
the
developers
tensions.
If
it's
okay
with
you,
okay,.
S
So
I'm
I'm
excited
to
see
the
interest
in
the
working
group
in
the
work
and
I
agree
with
your
statement
about
Davis's
statement
about
how
it
works
we've.
This
came
about
because
in
MANET
we
were
doing
the
routing
protocols
and
we
we
had
stuff
like
drivers
for
certain
Wi-Fi
cards
and
when
we
went
off
to
a
new
one,
you
had
to
redo
all
that
stuff.
So
it's
just
the
interface
that
lets
the
routing
protocols.
Talk
to
the
lower
layer,
lets
lower
layers,
talk
to
routing
protocols
and
then
swap
out
two
pieces
it.
R
One
of
the
things
we
came
out
with,
while
we
were
working
on
D
lap
was
it
really
is
as
lair
two-and-a-half.
It
doesn't
talk
about
layer
two
intentionally
and
it
doesn't
talk
about
what
you
do
at
layer,
3
with
the
information.
It's
it's
literally
a
way
to
get
that
layer,
2
information,
2
layer,
3
without
defining
how
what
you
do
with
it
when
you've
got
it
and
how
you
got
it
is
both
of
those
things
are
out
of
scope,
its
tries
to
stay
focused.
It's.
U
Interesting
there's
different
perspectives
on
on
deal
up.
I
was
just
mentioning
to
Dave
that,
if
develop
is
all
about
discovering
Ethernet
endpoints
and
no
it
has
this
ability
to
do
what
some
people
used
to
call
augmented
routing.
So
it
also
gives
you
some
next-level
information
with
some
IP
addresses,
but
for
me
the
Ethernet
discovery
or
the
endpoint
discovery
is
far
more
interesting
than
what
it's
doing
at
the
IP
level.
So
you
get
end
points
and
you
get
resources
to
availability
to
those
endpoints.
U
C
R
R
It
would
be
great
if
people
keep
trimming
a
right
to
talk
about
this,
there's
of
course
other
topics.
So
those
are
the
things
we
need
to
consider
the
fact
of
where
the
work
would
benefit.
If
we're
going
to
develop
this,
because
there's
interest
here
and
interest
in
other
working
groups
only
through
your
out,
where,
where
people
won't
show
up
and
discuss
for
three
quarters
of
a
meeting
something
else
and
only
you
know
ten
minutes
something
something
like
this
we
do
want
to.
R
There
is
ongoing
work
in
many
on
extensions,
for
example,
then,
obviously,
we
would
like
to
continue
right.
So
if
that
is
something
that
would
be
interesting
here,
along
with
other
things,
for
example,
then
you
know
that
may
fit
so
we
haven't.
Necessarily
we
don't
have
a
specific
outcome
that
we
want,
because
of
course
we
didn't
know
how
much
interest
there
would
be
that's
service,
but
mostly
mostly
what
you
said
the
beginning
here
to
get
the
protocol
better
known
in
other
places
and
to
measure
that
that
interest.
C
U
Thanks,
the
zoom
level
of
this
I
appreciate
you
giving
me
some
extra
time
to
sort
of
or
some
time
to
answer
some
questions
that
we
have
on
that
are
very
draft
specific
about
how
we
proceed
on
the
draft,
because
there's
there's
some
different
options
available.
The
only
bad
part
is
I
was
far
more
interested
in
Rick's
presentation
than
I
am
in
mind.
I
mean
yeah.
I
want
to
be
able
to
go
forward,
but
Rick
was
going
to
talk
about
a
new
topic
and
please
correct
me
if
I
get
it
wrong
right.
U
A
new
topic
which
was
going
to
be
right
now
deal
up,
gives
you
information
to
a
sick,
a
destination
but
only
sort
of
one
metric.
What
about
if
you
have
multiple
has
or
multiple
ways
or
multiple,
maybe
even
just
multiple
cues
going
on
so
that
you
could
get
different
metrics
to
the
same
endpoint
and
I
thought
that
that
was
a
really
interesting
application.
I
was
just
talking
to
Dave
in
the
background
who's
not
paying
attention,
but
they
so
I
was
just
talking
about
Dave.
U
R
U
But
that
said,
I'm
gonna
try
to
get
some
answers
on
my
presentation.
So,
first
of
all,
what
are
we
doing
here?
We
have
a
couple
of
extensions
that
are
talking
about
different
types
of
flow
control,
so
keep
in
mind
that
we're
talking
about
packet
level,
although
we
say
packet,
it's
actually
frame
remember
these
are
really
Ethernet
things,
even
though
we
have
IP
addresses
everything
in
deala.
Well,
a
lot
of
things.
Indila
are
really
managed
at
the
Ethernet
level,
so
we
have
these
routers.
Then
we
talked
to
these
line
systems.
U
Sorry
we
talked
to
these
modems
and
we
have
talked
over
a
link.
We
call
them
sometimes
media
channels
right,
it's
the
same
stuff
as
what
C
camp
has
been
familiar
with,
and
we
have
the
ability
to
do
flow
control.
I
can't
point
to
it.
We
have
a
disability
control
from
in
the
direction
of
from
the
router
towards
the
modem.
Why
don't
we
only
doing
one
direction?
Why
are
we
doing
fully
symmetric?
U
U
One
is
really
really
simple,
and
that
is
the
pause,
extension
and
think
of
this
as
X
on
X,
off
or
PFC,
if
you're
familiar
with
the
Ethernet
world,
but
you're
doing
it
on
a
destination
basis,
and
you
also
have
the
ability
to
do
it
not
only
on
a
destination
but
a
destination
per
dscp.
So
one
of
the
things
that
Rick
talked
about
is
is
that
these
radios
are
often
IP
aware
and
the
way
they
they
cheat.
They
they,
while
they're,
really
forwarding
on
a
MAC
address.
U
They
also
go
look
at
the
at
the
dscp
and
it
is
true
that
there
are
certain
radios
out,
there's
actually
even
forward
on
IP
addresses
I'm,
not
that
you
guys
know
me
more
from
the
sea
camp
world
I
know
more
about
the
sea
camp
world
I,
don't
know
about
these
radios
then
built
what
never
worked
on
well.
I
never
touched
one,
so
you
know
some
of
the
people
in
the
room
may
say:
yeah,
IP
radios
are
really
it
and
your
perspective
on
Ethernet
is
a
little
biased,
but
but
there's
both
markets
out
there.
U
So
we
have
pause,
that's
the
really
simple
one,
and
then
we
have
something
which
is
a
credit
based
approach
and
the
the
value
here
is.
You
can
keep
the
line
full.
If
you
have
a
credit
based
approach,
the
router
can
know
what
it's
different
credit
windows
are
and
only
send
traffic.
When
there's
credits
available
in
the
pause
mechanism,
it
has
you
have
to
get
a
message
that
says:
stop.
U
So
what
happens
when
you
say,
stop
well
you're,
not
necessarily
keeping
everything
full
with
credit
windows.
You
can
be
more
efficient
about
your
your
utilization
and
also
the
routers
can
have
a
better
idea
of
making
sure
that
the
the
right
priority
stuff
is
being
forwarded
on
to
the
radio.
So
the
big
thing
with
with
pause
is
let's
be
simple.
The
credit
is,
let's
be
as
efficient
as
possible.
Both
of
them
operate
on
a
Mac
destination,
plus
a
dscp
basis.
U
We
had
a
bunch
of
discussion
at
the
last
meeting
about
that.
We
would
like
to
optimum
maximize
the
reuse
of
data
elements,
the
data
items.
What's
the
data
item,
we
would
call
them
TL
DS,
so
we
want
to
maximize
reuse
of
data
items
between
different
extensions
and
we
had
actually
had
a
lot
of
parallelism
in
the
two
extensions,
but
not
exactly
reuse,
and
we
talked
about
trying
to
optimize
it.
U
We
took
an
action
to
do
it
and
we
looked
at
it
and
said:
are
you
sure,
because
it
feels
like
we
have
extra
processing
in
this
simple,
simple
scenario
of
pause
that
yeah
it
looks
nice
for
the
control
plane
perspective
and
it's
nice,
you
get.
You
know
you
save
the
code
point
when
we
have
what
to
the
16
code
points
available
and
why
not
make
it
just
easier
for
everyone
implement.
The
counterpoint
is
well.
U
If
I
have
all
these
objects
it's
easier
to
implement,
if
I
only
have
two,
if
I
implement
a
common
set,
so
there's
a
trade-off
there
and
that
the
fundamental
question
I
wanted
to
ask
the
working
group
is:
which
way?
Do
we
go
so
keep
that
in
mind?
That's
that's
what
that's
gonna
be
the
punchline,
so
oh
I
basically
talked
to
this
slide
and
said
you
know
it's
nice
to
reuse
ideas,
and
one
of
the
ideas
was
actually
Rick's
is
that
we
should
introduce
something
called
a
sub
data
item:
sub
TLV,
hey.
U
U
Independent
of
that
question,
maybe
I'll
jump
to
that
question
and
then
come
back.
We
have
a
question
of
how
many
documents,
because
we've
ended
up
doing
some,
a
bunch
of
core
extension
like
one
core
extension
to
the
protocols,
the
sub
data
item.
Another
one
is
the
concept,
the
product
windows
and
the
last
one
is:
how
do
we
identify
them
and
yeah
actually
I'm
going
to
talk
about
this
little
sorry
going?
U
U
The
other
thing
is
that
we
said
in
the
past,
and
the
working
group
we've
talked
about
is
identifying
baseline
Ethernet
priority
code
point
is
an
interesting
use
case
versus
dscp
s,
and
that
would
be
a
reason
why
you
want
to
have
these
reusable
objects,
so
you
could
do
that
so
to
convince
ourselves
that
we
actually
had
a
viable
building
block
approach.
We
did
a
definition
for
Ethernet
PCP,
and
the
question
is
whether
we
want
to
do
something
more
than
keep
that
as
an
appendix
this.
A
notional
thing
making
it
real
was
actually
really
little
work.
U
It
doesn't
take
a
whole
lot.
Do
we
want
to
do
that?
So
we
came
up
with
a
recommendation.
We
think
the
sub-items,
the
house
set
of
items
work,
that's
a
good,
independent
piece
of
work
that
should
be
published.
It's
basically
the
definition
of
sub
TLV
formats
and
in
the
protocol
that's
a
core
extension.
It
should
stand
on
its
own.
U
B
R
R
U
U
R
R
U
S
I,
don't
have
a
strong
opinion
either
way.
Okay,
I
think
more
towards
the
point
of
having
too
many
documents.
If
there's
going
to
be
a
use
for
having
them
split
up,
then
I
think
we
do
it
that
way.
If
we're
going
to
just
split
them
up,
because
there
may
be
a
use
sometime
in
the
future,
then
I
don't
think
it's
a
good
idea
that.
U
S
B
F
R
U
U
The
we
would
have
a
flow
control
identifier
iron.
Instead,
you
just
want
to
make
that
a
generic
flow
identifier
and
that's
actually
where
we
had
talked
about
that
the
last
meeting.
So
we
certainly
can
do
that.
I
think
we
should
talk
a
little
bit
or
whether
we
really
want
five
documents
versus
maybe
put
it
into.
R
That
works
for
me,
I
I
tried
a
first
pass
at
the
flow
ID
draft
and
75%
of
it's
absolutely
trivial
and
the
last
25%
I
don't
have
the
answers
to
all
the
questions.
It's
it's.
The
corner
cases
are
really
hard
and
I
would
like
some
help
working
on
it.
But
I
think
this
is
a
good
proposal
to
start
look
through.
U
The
details
on
this,
what
I
call
this
this
card
adoption,
because
one
of
the
key
things
is,
we
really
wanted
to
do
the
work
upfront
on
the
session
part
and
because
we
were
doing
the
work
upfront
on
session
and
only
a
very
little
bit
when
an
endpoint
showed
up.
It
meant
that
we
reorganized
the
data
a
little
bit
yeah
and
if
you
get
it
just
if
you
distributed
it
on
one
hand,
works
that
more.
It
works
more
naturally
for
the
objects,
but
it
does
the
wrong
thing.
L
U
U
Now
the
one
last
thing
is
I'm,
going
to
give
a
shameless
plug
before
one
of
my
co-authors
he's
put
out
open
source
code
on
deal
app
and
you
can
get
that
off
of
the
MIT
Lincoln
lab
repo
and
he
is
in
a
process
of
working
on
some
of
the
extensions,
the
ones
that
just
went
last
through
last
call
and
before
I
left.
He
had
one
of
them
almost
ready
to
go
last
week.
U
R
U
U
Last
thing
I'll
say:
is
we
had
two
documents,
two
other
extensions
that
I
think
passed
last
call
and
I
just
wanted
to
know.
Have
they
passed
last
call?
Okay,
so
the
chair
say
they
think
it
passed.
Last
call
so
I
look
for
that
the
Shepherd
right
up
at
that
getting
pupper
quest,
thank
you,
I'm
sure,
I'm
overtime,
but
questions.
R
I'll
go
very
quickly
through
this,
because
Lewis,
basically
really
the
primary
thing
I
want
to
talk
about
is
the
link
extension
link,
identifier
extension:
if
those
of
you
who've
read
it
there
was
some
discussion
on
the
list
everywhere
seems
to
be
rough
consensus
that
it's
in
good
shape
pushed
out.
One
last
version
today
with
the
latest
updates
from
jasser
on
the
list
and
we'd
like
to
go
for
last,
call:
please
chairs!
That's
my
critical
bet
on
that.
This
get
this
off
the
meeting
materials
reading
your
own
spare
time.
This
is
about
the
discussion.
R
The
Lu
and
I
have
just
had
about
splitting
our
traffic
class
identifier
and
trying
to
reuse
them
to
talk
about
flows.
I
have
a
question
which
I'll
take
offline
with
lo
at
some
point
and
anyone
else
who's
interested
by
whether
the
pause
is
actually
talking
about
a
local
queue
which
is
different,
so
I
prefer
to
have
a
queue
ID,
which
is
a
different
concept
from
a
flow
ID,
which
is
why
I've
got
that
strange.
R
S
Justin
Dean,
just
in
terms
of
last
calling
it
I,
have
to
take
a
look
at
it
again,
but
as
soon
as
I
do
that
I
think
that's
a
reasonable
thing
to
do,
and
me
and
Stan
will
talk
about
finishing
last
cults
up
in
pushing
in
doing
the
thing
that
Luud
talked
about,
because
there
have
been
discussions
and
documents.
Revd
and
I
think
we're
at
a
point
where
we
can
do
that.