►
From YouTube: IETF96-TRILL-20160721-1830
Description
TRILL meeting session at IETF96
2016/07/21 1830
B
C
A
E
A
E
Irst
I.
F
D
C
D
E
Is
chimed.
D
E
G
D
H
D
C
Hi
folks,
this
is
trill.
If
you're
working
for
drill
come
toward
the
front,
so
we
can
hear
you
otherwise,
the
chairs
feel
lonely.
So
we
are
going
to
get
started
with
Eden
with
the
administrivia
Donald.
C
How
many
people
written
in
oh
well,
Margaret,
okay,
please
note
well
than
anything
you
say,
is
a
contribution
in
the
working
group.
Please
read
these
noels
to
find
out
what
that
means
to
you.
Okay,
let's
go
to
the
next
one.
The
document
review
is.
We
are
progressing
a
lot
of
documents.
We've
been
working
on
for
two
to
three
years.
Please
read
them.
Many
of
you
have
been
very
active,
but
we're
in
that
final
push
and
we're
creating
a
lot
of
our
seas
from
all
the
good
work.
C
So
please
read
the
documents-
and
this
is
our
schedule,
where
we're
going
to
do
this
administrivia
for
a
few
minutes,
we're
going
to
do
status
and
milestones
and
then
Margaret.
Are
you
ready
for
Trillo
over
IP
good,
then
we'll
do
a
presentation
by
donal
and
you
sow
and
then
the
Charter
Review,
because
Bob
is
presenting
in
int
and
I
believe
Margaret.
You
have
to
go
to
in
tazewell
afterwards.
So
hopefully
our
time
is
work.
C
C
So
our
last
three
have
been
adopted
very
good
work.
We've
got
some
more
in
process,
go
ahead,
they're
in
the
editors
crew.
We
have
a
trill,
I
F
sub
TV.
We
have
trill
IRB
and
we
have
tral
tree
selection.
Thank
you
to
the
authors
for
the
hard
work.
There
is
a
call
back
from
the
isg
on
RP
optimization,
but
I
believe
the
authors
are
working
through
that
quickly
and
there
is
a
channel
to
channel
that's
in
working
group.
Last
call
and
the
following
have
passed
working
group
last.
C
Call,
which
means
read
and
review
were
making
quite
a
lot
of
progress
thanks
to
all
the
authors
and
Donald's,
and
we
have
less
call
for
tree
centralization,
replication
and
resilient
trees,
and
we
have
other
drafts
now
the
trail
working
group,
the
yang
traps
were
sitting
in
hold
because
the
lime
working
group
had
not
finished
its
work.
It
is
in
working
group
last
column.
We
anticipate
these.
C
C
And
I
will
have
a
chartering,
regis
discussion
and
I
think
that's
it
so
now
Margaret
will
do
the
king
and
hopefully
we'll
get
through
everything.
So
you
can
see
the
Charter
and
discussion
before
you
go
to
enter.
I
That
might
be
good
because
I
there's
quite
a
lot
of
noise
out
there.
There
are
two
different
drafts
that
need
to
provide
data
security
that
are
going
through
the
working
group.
At
the
same
time,
one
of
them
is
the
our
bridge
channel
draft
draft
IETF
to
elaborate
channel
10,
and
one
of
them
is
the
trill
over
IP
draft,
which
is
it
draft
IETF
trail
over
IP
6.
I
Okay,
both
of
these
drafts
have
the
seam
need,
which
is
that
they
need
a
way
to
do
a
multi-party,
keying
right
right
now
they
can
do
point
to
point,
but
they
can't
do
point
to
multipoint
securely
and
so
a
donalds
come
up
with
a
way
to
do
that
which
is
defined
in
this
third
draft,
which
I
think
I
go
okay.
They
both
need
group
key
and
he's
come
up
with
a
way
to
do
this.
I
With
a
with
the
point-to-point
King
defined
and
say
that
mom
group
King,
is
kind
of
left
to
future
work
and
then
publish
the
group
keen
document
and
then
publish
how
it's
going
to
be
used
by
the
channel
tunnel
and
what
we
want
to
do
basically
is
put
trill
over
IP
in
that
same
bucket
to
advance
it
with
the
point-to-point,
define
work
on
the
group
keying,
which
may
take
us
a
little
while
to
get
right
and
then
document
how
both
trill
over
IP
and
the
Channel
Tunnel
draft
would
use
group
king
to
allow
point-to-point
point-to-multipoint
to
be
done
securely.
I
Right
now,
currently,
if
we
did
want
to
do
a
multicast
messaging
and
we
wanted
to
do
it
securely-
we'd
have
to
serialize
and
turn
a
point-to-multipoint
message
into
a
number
of
point-to-point
messages
and
and
the
trill
over
IP
draft
already
explains
on
how
to
do
that.
But
it's
inefficient.
So
it's
not
that
things
wouldn't
work,
but
we'd
be
able
to
define
another
draft
on
how
to
do
it
more
efficiently.
I
There's
a
group
king
solution
document
that's
been
designed
and
is
currently
in
draft
eastlake,
trill
group
keying.
It's
just
just
come
out
as
an
individual
draft
between
the
last
two
IITs
it
securely
distributed
shared
keys
to
the
group
members.
So
in
the
case
of
multicast
traffic,
the
members
in
that
multicast
group
arm
it
provides
King
from
multicast
and
broadcast
arm,
but
which
group
member
originated.
I
The
packet
is
not
known,
so
there
would
be
a
group
key,
and
you
could
know
securely
that
the
packet
was
originated
by
some
money
in
that
group,
but
you
would
not
know
who
in
that
group
originated
the
packet.
At
least
you
wouldn't
know
that
securely
that
could
be
spoofed.
So
this
is
how
how
we're
trying
to
solve
that
particular
problem.
If
authentication
of
a
particular
group
member
is
needed,
then
you
need
to
use
unicast
package.
I
You
need
to
use
point
to
point,
I'm
so
that
you're
actually
authenticating
who
sent
it
and,
as
we
said,
that's
less
efficient,
but
that's
already
supported
by
the
current
trill
over
IP
draft
and
also
by
the
current
channel
telegram.
So
we
have
an
idea
how
to
move
forward
here
and
it's
a
three-step
process.
I
The
first
step
would
be
that
we
put
both
the
channel
tunnel
draft
and
the
trill
over
IP
draft
through
with
the
point-to-point
key
and
the
way
to
use
it
securely
is
to
serialize
your
multicast,
send
it
to
each
point
directly
in
a
point-to-point
manner.
Then
we
write
a
key,
a
group
key
distribution
mechanism
which
we're
going
to
probably
need
a
lot
of
help
from
security.
Ron
we've
been
getting
help
from
the
security
area.
All
the
log
on
these
drafts,
so
I
assume
we'll
be
able
to
get
it.
I
When
we've
got
that
done,
we
write
a
draft
covering
how
to
use
that
group
king
mechanism
in
both
trill
over
IP
and
the
Channel
Tunnel
draft.
So
this
is
our
proposed
way
forward
which
will
get
us
unstuck
on
both
the
channel
tunnel,
which
I
think
we've
already
decided
to
move
forward.
This
way
right,
Donald
and
drill
over
IP,
which
we're
asking
the
working
group
to
also
agree
to
move
forward
this
way.
I
So
this
is
our
proposal
right
now
that
we're
asking
the
working
group
to
agree
to
and
the
plane
going
forward
shows
all
of
these
existing
drafts
and
what
new
drafts
we
would
be
planning
to
write
so
there's
trill
over
IP
and
there's
a
trill
channel
tunnel
and
those
are
our
two
deliverables
right
and
right
now,
we've
got
trill
over
IP,
06
and
I.
Think
we've
got.
D
I
Is
the
current
version?
Okay,
great
and
that's
already
passed,
IETF
last
call
with
only
the
point-to-point,
keying
and
transmission
in
it?
Okay.
So
what
we're
proposing
is
that
we
send
trill
over
IP
version
7
to
last
call
with
only
the
point-to-point,
king
and
transmission
in
it,
and
that
we
then
write
this
group
keen
document
which
order,
or
we
adopt
this
group
keying
document
that
Donald
has
already
written
I'm
assuming
we
we
like
the
contents
of
it
and
then.
I
We
end
up
writing
we
end
up
publishing
it
as
a
group
document
eventually,
and
then
we
also
write
a
document
that
explains
how
to
do
trill
over
IP
and
channel
tunnel
using
group,
teen
document
and
I
think
the
way
this
is
drawn.
That
would
be
one
other
document
that
explains
how
to
use
it
for
both
of
those
those
capabilities.
So
does
everybody
understand
what
it
is
that
we're
proposing
we
do?
I
Here
we
will
oh
and
then
later
on,
we
will
write
the
more
specific
draft
on
how
channel
tunnel
and
trail
over
IP
will
use
that
generic
group
King
draft,
and
we
will
also
will
try
to
publish
both
of
those
documents,
so
I
think
really.
What
we're
looking
for
is
feedback
from
the
group
on
that
plan.
Does
that
seem?
Ok,
any
concerns
particularly
we'd
like
to
know.
D
The
only
thing
I
would
say
is
that
when
the
the
plan
was
this
group,
keying
document
quarantine
dock
way
also
has
some
specific
stuff
about
Channel,
Tunnel
and
stuff,
when
it's
separated
out
in
the
01
version,
which
is
just
group
keying,
and
we
do
a
work
group.
Adoption
on
that
might
also
be
an
excellent
time
to
ask
for
security
review
by
somebody
in
the
security
area.
We.
I
Also
need
people
to
just
review
that
document
me
this
way,
we're
not
asking
the
working
group
to
adopt
the
group
keen
document,
as
Donald
said
it
needs
to
update
it.
It
also
just
needs
to
be
reviewed
by
people
in
this
group
as
well,
which
I
I,
don't
think.
We've
gotten
really
any
feedback
on
it.
I
Yet
it
also
so
please
review
that
document
as
well
as,
what's
up
here,
I
guess
we
can
make
a
request
to
say:
please
look
at
it
in
four
weeks,
they'll
be
like
a
cleaner
version,
but
it
would
be
really
great
if
we
could
get
some
feedback
on
that
document
sometime
in
the
you
know
next
couple
months,
so
that
we
can
possibly
updated
again
before
the
next
ikea
fifa,
if
there's
some
feedback,
so
anybody
have
any
questions
or
anything
nope
sounding
silence,
I'll
take
her
sounding
silences.
I
D
Okay,
thank
you.
Bargain
with
eternal
market
has
to
go,
give
%
something
else
in
int
area
and
also
Bob
Brisco
is
gonna
on
the
schedule
laid
here
is
currently
presenting
something
in
ND
area,
so
he'll
be
showing
up
here.
So
it's
that
the
far
is
it,
let's
see
a
little
extra
walking,
and
so
we
clearly
need
to
list
it
area
on
our
conflict.
Restaurant.
D
So
this
is
all
right.
This
is
intended
to
speed,
update
on
the
what's
going
on
in
the
directory
related
drafts
and
also
the
art,
optimization
draft,
which
was
returned
to
the
working
group.
So
it's
going
over
the
drafts,
there's
the
the
ia
absentee
lv,
which
is
at
the
end
the
RFC
editors
cute
as
a
data
format
draft.
So
we
were
hearing
about
this
channel
tunnel
draft.
D
It
supports
push
directories
and
pull
directories
hosted
on
our
bridges.
Where's
pull
directories
hosted
on
an
end
station
and
it
lets
other
our
bridges
extract
stuff
from
those
directories
and
out
of
a
diagram
showing
this
and
the
next
slide.
And
then
there
is
an
extension
graft
which
is
going
to
extend
the
access
to
the
directory
to
end
stations
and
I'll,
explain
in
a
sec.
Why?
We
want
to
do
that
so
there's
a
diagram
showing
what
it
can
do.
So
there's
a
push
directory
client
over
here
and
it
can
send
west's.
D
You
can
either
have
everything
pushed
to
it.
I
pantura
can
send
requests
to
it
to
a
full
directory
and
ease
the
a
single
R.
&Amp;
R
bridge
could
be
a
push
directory
or
a
pull
directory
or
both
or
you
know
whatever
it
wants
and
also
defines
how
to
send
pull
requests
through
a
proxy
and
find
what
the
proxy
does.
This
client
doesn't
know.
That's
Brock
see
it
thinks
the
pull
directory
is
here.
They
can
actually
be
on
an
end
station.
There's
a
mapping
that
occurs
here,
because
it
needs
to
send
some
more
information.
D
D
That
it
got
from
the
directory.
So
what
does
this
extension
graft?
Do
extensions
draft
allows
an
end
station
to
actually
send
polar
or
requests
or
to
get
stuff
push
to
it
from
a
client
proxy.
So
the
client
proxy
looks
like
it's
like
a
regular
bridge.
So
if
this
end
station
send
the
pull
request
it
sees,
you
can
see
this
client
proxy
here.
D
It
gets
forwarded
to
the
pull
request
full
directory
here
or
possibly
even
through
this,
to
a
full
directory
under
10
station
and,
if
stuffs,
being
pushed
oops,
sorry
stuffs
being
pushed
to
here
and
this
end
station
could
request
that
the
correct
stuff
we
pushed
out
to
it.
So
why
would
an
end
station
want
all
this
directory
stuff?
D
Well,
okay,
here's
a
page
on
the
clients,
graphs,
essentially
there's
the
ARP,
optimization
draft,
which
indeed
wants
directory
information
or
local
information
about
the
correspondence
between
IP
and
mac,
and
things
like
that
in
order
to
be
able
to
optimize
respond
locally
to
arps
or
neighbor
discovery,
or
things
like
that
and
there's
two
graphs
about
specialized
end
stations.
These
are
special
kinds
of
end
stations.
D
Capsulation
can
actually
do
address
learning
and
things
like
that
at
the
end
station,
so
those
would
be
potential
clients
at
end
stations.
Most
annotations
currently
don't
obviously
know
about
directory
services.
They'd
have
to
add
something
to
the
end
station
for
it
to
be
able
to
use
those
services.
D
So
that's
Jill.
Here's
what's
kind
of
going
on.
We
have
the
data
structure
is
in
the
RFC
editors.
Q
channel
tunnel
is
a
past
IETF
last
call
and
as
needs
a
little
bit
of
minor
changes
to
get
through
the
iesg
directory
system
mechanisms.
Leah
is
going
to
talk
about
that
in
a
second
it's
been
sent
back
to
the
working
group.
It
is
has
gone
through
a
working
group
last
call
and
the
ARB
ND
optimization.
Sorry
I
asked
a
friend
to
me.
Mv
optimization
graft
up
here.
This
is
the
directory
assistance.
D
One
has
been
through
the
last
call
it
needs
some
drum
review.
Comments
resolved
sorry,
it
is
the
directory
extensions.
This
is
a
dependency
graph,
so,
like
smart
n
nodes
would
have
to
use
directory
extensions
because
it
wants
to
get
to
the
directory
from
an
end
station
and
here's
the
main
directory
mechanisms
which
use
this
data
format
and
use
this
security
mechanism.
J
J
This
arbonne
ND
optimization
draft.
Actually
I
will
receive
some
deep
questions
so
its
return
to
the
walking
group
and
is
working
okay.
So
there
we
receive
the
straightest
castles.
We,
sir,
with
the
listed
points
here.
The
first
one
is
regarding
their
how
to
age
out
there
learned
address
by
the
edge
of
bridges.
We
didn't
touch
it,
so
actually
there
are
various
possibilities,
so
we
are
going
to
cover
it
in
the
next
revision.
For
example,
the
very
traditional
timeout
is
going
to
be
can
be
used
or
PA
periodically.
The
local
station
can
send.
J
J
Currently
we
are
leave
for
the
implementers
to
to
use
any
of
them,
but
the
suggestion
is.
We
should
give
some
guidance,
especially
actually,
when
send
the
security
and
ease
use.
Some
of
the
options
might
not
be
applicable.
So
that's
why
the
guidance
would
be
required
in
the
set
point
is
on
the
source.
Address
of
the
responses
for
the
ARP
should
be
synthesized
by
the
edge
a
preacher's.
This
part
we're
going
to
touch
it
in
the
next
room
business
as
well.
J
What's:
okay,
here's
a
continued
in
okay
for
the
for
the
swine
I've
kind
of
a
cover
it
all
ready
for
the
stand
we
should.
We
were
going
to
more
mark.
We
are
going
to
clearer,
clearly
specify
what
to
do
in
case
of
the
security
and
D,
since
some
of
their
options
should
be
ruled
out.
The
last
one
is
there
are
some
okay
questionable
keywords:
okay,
it's
going
to
be
fixed.
J
So
here's
the
plan
we
have
already
we
we
have
already
respond.
One
of
the
discuss
out
of
three
in
what
we
are
going
to
do
is
to
produce
an
opposed
and
updated
draft
to
incorporating
all
the
changes
agreed
by
ad
in
who
had
posted
the
disgust.
We
have
reached
two
out
of
three,
so
there
is
one
left
we're
going
to
reach
and
get
the
agreement
after
after
the
thing
is
here
listed
to
be
solved
out.
We
are
going
to
run
another
working
group
velasco
to
request
the
publication.
G
C
B
C
C
C
For
that
would
be
good
to
get
blue
sheets
we've
gone
through
standardizing
OEM,
active-active,
multi-destination
frame
reduction
directory
a
trail
over
pseudowire
and
over
p
multi-level
mullick
topology.
I
am
really
impressed
with
our
solutions
in
that
that's
just
the
chair,
since
I'm
not
the
author
on
all
of
those
the
reduced
control
playing
the
security
analysis
and
interoperability.
C
This
is
the
status
we've
gotten
RFC's.
We
have
drafts.
In
most
of
these
cases,
we've
gotten
almost
all
of
our
multi-level
topology
we've
got
pending
drafts
in
the
intercampus,
reduced
control,
plane
and
we've
got
pendant
to
drafts.
Based
on
the
security
analysis.
We
just
went
through
all
of
those
drafts
where
we
have
the
dependency
on
the
key,
and
we
move
this
stuff
on
the
interoperability
to
the
wiki.
Here
are
a
few
things
we
think
are
useful
for
the
the
working
group.
C
The
real
thing
that
we're
looking
for
is
just
as
many
things
are
moving
toward
st
enter
controller
we'd
like
to
make
sure
that
trill,
like
many
of
the
porting
protocols,
has
better
stn
support.
We
want
to
increase
our
transparency,
which
will
reduce
coupling
and
we
want
to
add
some
small
content.
Now.
One
of
the
interesting,
so
you
can
see
the
proposed
changes
here.
C
D
K
Only
Atlas
so
I
so
question
with
the
is
with
the
traffic
engineering,
because
traffic
engineering
can
be
sizable
and
the
question
here
is
who
needs
it?
What's
the
drive
and
motivation
and
there's
a
lot
of
really
cool
technology
in
trail,
but
there's
also
already
a
lot
of
complexity
and
I'm
interested
in
understanding
what
the
requirements
said
basic
where
the
operational
desire
to
use
it
is
what
the
applicability
is
and
I
mean.
You
produce
a
lot
of
really
good
documents,
but
it's
a
lot
of
documents
and
they
got
to
have
to
be
implemented.
K
C
K
C
C
D
Delia
I
can't
say
specifically
where
the
one
I
know
about
is,
but
he
still
is
used
in
several
internet
exchanges,
for
example,
and
that's
an
example
of
case
where,
depending
you
know,
you
whitewater
be
bored
is
transparent,
as
you
could.
Okay,
the
server
learn,
exchanges
in
Eastern
Europe,
particularly
in
burb
sure.
C
D
D
H
C
Okay
and
again
just
to
help
our
ID,
my
understanding
of
six
and
the
deployment
characteristics
is
number
six
where
you
reduce
control
plane
and
our
debt
excellent
error.
Isolation
was
to
deal
with
some
issues
as
well
in
deployment.
That's
what
Allah
is
asking
its
deployment
questions
yeah
well,.
K
I'm
saying
I
guess
what
I'm
saying
is:
you've
got
a
lot
of
good
technology,
but
a
lot
of
complicated
and
some
point.
We
need
to
pause
and
say
how's
it
going
with
the
industry.
What
are
they
using?
Can
we
start
moving
to
supporting
operational
deployment
concerns
as
a
potent
issues,
as
opposed
to
expect
yeah
that.
C
C
K
G
D
Were
originally
money,
they're
they're
critical
bits
now
and
then
these
are
treated
as
such
by
existing
silicon,
and
so
you
could
use
a
field
in
there
for
payload
type
and
it's
basically
just
for
you
know,
I'm,
not
including
unnecessary
field
like
in
this
IP.
You
don't
need
to
mac,
addresses
and
stuff
like
that,
and
it
can
be
done
safely
because
existing
version
silicon
will
trap
such
packets.
And
if
you
are
about
to
forward
to
a
a
trill
switch
which
doesn't
support
that
feature,
then
you
can
in
fact
expand
the
packet
and
make
it
compatible.
D
D
B
C
Yeah
name
change,
because
life
is
been
crazy
with
people
miss
consuming,
but
that's
a
middle.
That's
a
minister
via
moment.
Ok,
so
I
think
we
need
a
discussion
with
the
ad
on
the
one
point
on
te.
I
think
the
rest
of
them
Donald.
Did
we
hear
anything
new
I
wish
I,
don't
know
that
John's
got
this
job
is
John
got
feedback
in
there
on
I,
didn't.
K
So
one
thing
this
is
brainstormed
on
the
fly,
so
you
could
take
it
for
all
it's
worth,
but
one
thing
that
might
be
interesting
to
think
about
is
something
along
I
guess
something
like
a
deployment
experience
or
applicability
there
or
profile,
or
you
have
there's
an
awful
lot
of
different
options
and
pieces,
and
it
might
be
really
nice
to
have
sort
of
a
map
of
this
is
a
this
is
a
piece
of
it
that
worked
well
together
to
solve
particular
applicability.
Yeah.
K
D
A
spectrum
of
things
which
might
be
because
all
it
will
tries
to
be
zero
configuration.
There
are
things
you
can
tweak
here
and
there
and
there's
also
things
people
have
encountered,
which
blindly,
following
the
letter
of
the
spec,
turns
out
not
necessarily
quite
be
the
right
thing,
in
particular
cases
where
you
might
be.
E
B
C
D
Yes,
yeah,
the
ecn
stuff
is
basically
exactly
they're
tweaking
some
bits
in
the
header.
Essentially
so
I
don't
know
you
know
buddy,
it's
not
explicitly
called
out
as
a
work
item,
certainly,
but
it's
so
I
think.
Okay,.
C
C
D
C
D
D
J
C
Most
of
the
trill
yang
models:
well,
they
have
both
OEM
and
regular
configuration,
but
I
didn't
check.
I
need
to
go
back
after
they
finish
the
lime
stuff
to
even
look
at
the
OEM
models
for
error
statistics
because
they
were
first.
F
D
Cities
in
here
are,
we
now
have
a
15
minutes
left.
So
what
a
nice
en
explicit
congestion
notification,
nope
I,
know
how
many
people
are
aware
of
it,
but
basically
the
provides
we're
sort
of
indication
going
down
the
stack.
This
is
higher
level
applications
and
there
for
over
33
place
the
IP
layer
2
down
here,
indication
that
it's
ecn,
compatible
parents,
work,
yeah,
capable
ecn,
capable
transport
is
indicated
on
the
way
down
and
congestion
experienced
on
the
way
up.
D
So
the
idea
is
that
the
far
end
knows
whether
some
data
received
ran
into
a
congested
packet
thing
along
the
way
course
the
condition
was
severe
enough.
The
data
won't
ever
get
through
at
all.
But
usually
you
don't
have
you
know
a
sudden
blockage.
If
nothing
is
getting
through,
then
you
no
longer
have
adjacency
and
other
mechanisms
will
work,
so
it
just
congested
it
prudently.
Just
some
of
it
will
get
through
in
that
can
all
be
mark
yep,
okay.
D
So
the
idea
is
that
you
can
mark
in
IP
these
days
whether
it's
easy
incompatible
and
you
can
mark
whether
it's
experient
condition
so
0
there's
some
bits
which,
when
there's
zero,
just
sort
of
this
default
means
it's
not
ecn
compatible
and
if
there's
100
one
means
it
is
ecn
capable
and
411
means
the
experience
congestion.
So
normally
IP
does
flow
control
based
on
the
loss
of
packets.
But
if
you've
lost
the
packet,
then
the
day
didn't
get
through
and
you've
kind
of,
not
in
as
good
a
shape.
D
K
K
K
D
G
D
Yeah
so
there's
this
optional
flags
word,
which
has
a
few
bits
defining
it
currently
like.
If
you
need
a
bigger
hop
count,
you
can
put
it
there
or
similar
bits.
So
the
idea
is
to
put
this.
The
current
sort
of
ecn
field,
like
you,
have
an
IP
fits
in
a
couple
bits
over
here
and
including
a
value
which
is
the
non-critical
congestion
experience,
which
is
slightly
renamed
for
our
fill
application
and
there's
also
a
bit
over
here.
D
So
in
this
flags
were,
there
are
some
bits
that
are
predefined
to
be
critical
and
some
bits
that
are
predefined
to
be
non
critical
and
we
can
have
a
critical
congestion
experience
flag
over
here.
So
what
happens
is
when
you
have
traffic
from
the
end
station,
the
ingress,
our
bridge
copies
the
ecn
field
from
an
IP
header
or
if
it
happens,
to
understand
some
other
protocol
into
the
troll
header
and.
D
This
is
a
then
you
go
through
some
transit
playing
it
and
some
of
these
transit
link
spine
doc.
Sexy
might
not
actually
be
ecn,
you
know,
aware
or
but
that's
okay,
and
if
you
get
one
where
it
is
and
there's
congestion
experience,
namely
they're
cute,
but
for
cues
are
too
big
or
whatever
it
marks
it
using
the
the
critical
flag
and
it
doesn't
actually
bother
to
check
whether
the
transport
is
ecn
capable
or
not.
So
basically,
the
ingress.
You
should
do
this
copying
the
transit
things
just
need
to
if
they
experienced
congestion.
D
K
Let's
again,
no
hats,
but
so
when
I've
seen
ecn
implemented
in
routers,
it's
generally
that
you're
setting
it's
as
part
of
its
part
of
the
egress
cueing
or
verbal
cueing.
Depending
on
what
kind
of
game
you
play.
But
the
point
is
you
set
the
bit
as
it's
going
into
the
queues
which
is
frequently
well
after
you've
done
any
of
your
header
manipulation.
D
K
I
would
request
that
people
who
have
hardware
implementations
take
a
serious
look
at
this,
because
if
what
you're
saying
is
as
long
as
your
do
a
CN,
you
need
to
put
the
word
in
that's
fine,
but
they
need
to
it
that
comes
with
its
own
cost
and
normally
ecn
doesn't
really
come
with
a
heavy
cost
to
implement.
But
the
idea
that
you're
going
to
have
the
hardware
I
am
not
as
familiar
with
switches
as
I
am
with
routers.
K
You
know,
Mia
culpa,
why
not
that
much
difference,
but
what
I
have
seen
of
switches
is
pretty
darn
similar,
particularly
at
the
qos
level
and
I
think
that
what
you
are
describing
would
be
if
you're,
optionally,
adding
it
when
you
see,
if
you
expect
to
optionally,
add
it
when
you
see
convergent
congestion,
I,
don't
think
there's
going
to
be
a
lot
of
uptake,
so
really
really
really
talk
to
folks
who
are
doing
the
hardware
implementation,
okay,.
D
Sure
it
needs
be
looked
at
more.
I
would
say
that
in
all
forms
of
compatibility
really
good
and
macro
compatibility
in
real
world,
if
it's
in
a
data
center
or
something
very
likely,
all
these
things
will
be
the
same
capability
level.
So
if
some
support
is
it's
implausible
that
you
have
randomly
scattered
ones,
it's
for
dcn
and
once
it
done,
and
in
which
case
the
ingress
will
always
add
the
word
as
part
of
the
ingress
in
cap.
Oh.
D
Don't
say
that
it's
like
I
think
we
refer
to
the
trill
switch
is:
is
it
a
real
layer?
3
router
I
mean
it
logically,
it
throws
away
the
layer,
2
header,
look
at
the
next
nickname
and
adds
a
new
layer
to
header.
So
it's
it's.
It's
really
a
router.
It
just
routes
on
nicknames
instead
of
on
IP
addresses
what.
D
C
D
D
So
what
are
the
changes
as
a
draft?
Oh
one
has
just
been
posted,
so
there
were
several
wait.
Several
different
options
presented
the
last
time
and
we
decided
to
change
from
opportunity
three,
which
basically
means
changing
from
classic
ecn
to
this
technique
to
use
a
critical
bit,
because
that
gets
you
the
benefits
of
ecn
to
considerable
extent,
without
having
to
assure
that
the
egress
supports
ECM
and
actually
yours
doesn't
support
easy
and
you
don't
really
quite
get
the
benefits
of
ECM.
D
At
least
you
get
the
traffic
discarded,
so
you
get
the
IP
flow
control,
rename
the
soups
alright
renamed
a
couple
fields,
as
indicated
earlier,
and
there's
a
now
a
section
in
the
draft
on
support
for
ECM
variants,
including
free
congestion,
notification
and
0
4
s
which
had
a
successful
boss
on
Tuesday
and
that's
I.
Don't
know
if
I
remember
the
full
expansion
I
don't
put
on
the
next
it,
but
it's
right
here:
low-latency,
low-loss,
scalable
throughput,
otherwise,
the
data
center
TCC,
you
kind
of
stuff
and
their
graphs
by
Bob.
D
It's
not
here,
and
the
idea
is
that
you
want
to
discard
with
a
an
appropriate
probability
and
if
you
do
things
right,
which
this
is
the
classic
q-
and
this
is
the
one
L
4sq
does
you
can
get
a
very
low
latency
with
Rowley
low
loss
and
high-throughput.
So
this
is
not
a.
This
is
not
required
or
anything
with
troll,
but
the
markings
that
are
being
done.
The
support
tab.