►
From YouTube: IETF98-BIER-20170327-1300
Description
BIER meeting session at IETF98
2017/03/27 1300
A
A
B
A
B
C
D
People
are
still
flowing
in
we've
got
a
pretty
short
agenda,
but
I
did
put
some
in
the
end
for
open
discussion,
which
I
think
worked
really
well
and
so
last
year
or
last
year,
last
meeting
and
last
year.
So
we've
got
some
kind
of
turning
points
in
the
and
the
working
group
that
we
want
to
address.
So
this
chance
for
open
mic.
But
let's
let
it
roll
a
little
bit
couple
of
minutes.
You
guys,
okay
with
that
letting
people
come
on
in
remember,
to
leave
your
shoes
at
the
door.
D
D
Right,
look
at
the
doors
are
settling
down.
Welcome.
We
are
at
the
beer
working
group
meeting
Chicago.
If
you
don't
mean
to
be
in
Chicago
I'm.
Sorry,
you
took
a
wrong
flight,
you
don't
mean
me
the
beer
working
group.
You
got
the
wrong
door
over
here,
let's
start
with
some
housekeeping
stuff.
To
begin
with,
we
need
someone
to
take
minutes.
We
need
a
jabber.
Scribe
is
the
hardest
thing
to
do
for
the
chairs
to
get
someone
to
say
yes,
but
doing
it's
not
that
tough
and
I
found,
especially
if
you're
fairly
new
to
the
IETF.
D
It's
a
great
way
to
keep
you
engaged
in
the
process.
You
start
learning
names,
you
start
learning
the
dialogue
and
then
there's
an
exchange
that
takes
place
afterwards
with
the
chairs
on
you
know
affirming
what
the
actual
events
were
so
I
encourage
people
who
haven't
done
it
before
please
step
up
and
consider,
if
not,
we
assign
you
and
then
you
get
none
of
the
love
that
we
spoke
up.
D
D
Trouble
is
I,
look
up
and
I've
already
like
forced
it
on,
and
all
the
people
that
I
know
up
front
and
I
won't.
Do
that
to
you
twice
I
see
up
here,
I've
done
it
to
you
before!
I
won't!
Do
it
to
you
again
so
I
like
to
someone
new
jump
in
if
possible.
I
think
that
over
gentlemen,
the
white
beard
here
is
fairly
new.
The
idea
of
I
haven't
seen
him
in
years.
Oh.
D
D
D
D
D
D
All
right
this
is.
We
currently
have
our
agenda.
It's
pretty
darn
light,
in
fact,
I
think
some
of
this
should
go
fairly
quick,
but
maybe
one
point
of
discussion
that
could
be
interesting.
I'm
expected
a
bit
more
because
we
had
some
stuff
that
came
out
of
the
interim
group
and
some
development
took
place
and
so
low,
but
that's
all
right,
I
think
we're
going
to
push
our
discussion
to
the
end,
which
is
some
interesting
points
to
move
our
work
forward,
all
right
anything
to
bash
on
this
anything,
I'm
missing
anything.
D
It
should
not
be
on
the
agenda.
Oh
I
know
that
guy
you
got
so
lucky.
We
are
assigning
minutes
to
the
next
guy
in
the
room,
yeah
you're
awaiting
exactly
well,
not
all
right
with
all
those
tears
of
affirmation.
I
assume
you
think
this
agendas,
fine,
it
will
move
on
excellent.
Okay.
First
up,
then,
is
Pierre.
H
Alright,
so
that
was
presenting
this
the
last
time,
I
slowed
since
then
they
be
merged
with
this.
Autograph
had
also
talked
about
Iran
MLD.
That's
why
there's
a
few
extra
office
for
now,
so
I,
don't
really
want
to
spend
much
time
on
this,
since
this
has
been
presented
both
by
me,
I'm
here
before,
but
basically
they're
using
FML
d,
or
also
I
again
arjun
heat
as
an
overlay
or
gear
signaling,
so
I'm,
basically
livid
here,
you
wanted
signal
from
the
same,
be.
H
Mike
and
Evie
box,
okay,
so
basically
you
want
to
have
the
egress
router
spy
receivers.
You
know
the
ingress
routers
by
the
source
over
there
that
they
are
interested
in
you
see.
So
what
we're
doing
is
we're
sending
MLV
origin
p
packets
with
your
end
cap
too,
can
be
a
subset
or,
like
all
the
all
the
routers,
and
I
don't
know
on
the
ingress
side,
you
are
doing
explicit
tracking,
so
you're
not
exactly
which
each
routers
are
interested,
so
it
can
fit
up
the
beer
in
cap
for
the
appropriate
bit
sets
next.
H
So
we
added
to
a
trip
day
the
drafty
presented
last
time
and
we
added
an
appendix,
which
is
a
use
case
that
comes
from
this
other
draft,
but
basically
talks
about
beer
in
the
data
center,
including
the
excellent
and
kept
the
document.
Apart
from
that
appendix
the
document
hasn't
changed,
so
it's
been
the
same,
stable
form
for
fine,
except
at
appendix
that
the
grafted
merged.
With
a
proposed
some
changes
to
the
mov
message
format.
You
have
taken
that
alpha
don't
want
to
make
any
changes
to
mov
itself.
H
You
just
want
to
use
em
lbs
per
signaling
and
it
actually
have
implemented
this
and
it's
been
tested
by
some
few
different
companies.
Organizations
forever
so
form
the
data
center
and
that
appendix
we
might
want
to
think
a
little
bit
more
about.
Is
there
something
we
can
do
differently
or
better,
but
the
main
part
of
the
documents
also,
this
is
stable,
so
next
slide
not
blossom
occasion,
so
yeah,
so
basically
I
will
not
maybe
Oscar.
This
can
be
adopted.
H
D
Address
first,
the
history
just
a
little
bit
just
kind
of
refresh,
because
you
said
this
added
appendix
from
the
previous
trap.
I
think
the
idea
from
the
working
group
which
to
roll
that
work
in
and
abandon
that
draft.
That's
not
it
yeah!
Okay,
because
we
consolidate
remember
in
curtain,
solar
reaction
talked
about
this
consolidated
capsulation.
We
had
a
various
capsulation
giraffes
that
were
kind
of
stacking
up,
and
we
focused
all
that
the
unified
solution,
but
there
were
some
ideas
than
in
that
particular
in
cap
draft
that
we're
overlapping
with
MLD.
D
So
we
got
those
people
together
this
why
the
author
list
is
a
bit
large,
but
it
was
inclusive
and
bringing
the
costs
together,
and
so
this
is
the
direction
that
we
chose
to
go
forward
from
initially
from
the
interim
meeting
and
then
agreed
upon
its
soul.
So
what
you're
asking
is
this
is
something
for
adoption.
Give
you
some
history.
This
should
see
feel
for
the
room,
the
raise
of
hands
who
thinks
this
is
working
group
adopted
worthy
okay.
D
C
D
I
Hello
arrow
on
here
comes
the
young,
datamodel
4000m
I'm,
not
a
family
who
I'm
wrong
and
because
the
author
of
Allah,
who
has
hasn't
been
here
for
some
personal
affairs,
so
I
present
it
on
behalf
of
him
and
also
on
behalf
of
myself,
the
motivation
and
the
background
of
this
draft.
This
is
the
new
drug.
This
document
defines
the
young
data
model
from
here
om,
that's
what
it
does
and,
as
we
know
there
is
a
basic
young
data
model
in
the
line
work
group,
layer,
independence,
om
management's.
This
draft
is
the
extension
of
that
draft.
I
First,
the
let's
have
a
quick
look
at
about
the
architecture
of
OEM
young
model
and
its
relationship
with
the
bureau
em
in
the
top
it's
the
generic
OEM
young
and
which
is
the
PASOK
for
order.
Connectionless
OEM
young
model,
which
we
can
find
it
in
a
line,
work
group
and
it's
an
under
that
it
divides
into
several
technology-specific
young
om
on
the
FFC
service
function.
D
D
D
D
H
G
D
D
Sweet
so
so
I
mean
those
of
us
in
the
room
if
stepped
in
multicast,
either
recently
or
decades
ago.
We've
been
tracking
around
our
careers
right,
you
can't
get
rid
of
it,
but
the
reality
is
a
lot
of
people
who
don't
spend
time
and
multicast
often
dismiss
it
and
think
it's
like
something
can
do
later
and
bolting
it
on
after
the
fact
is
non-trivial.
So
it's
great
that
we
have
multicast
experts
working
on
yang
requirements,
and
so
we
need
to
roll
to
beer
folks
into
that
Network.
I
And
you
both
connect
later
on
and
the
Nexus
telework
nargis
the
next
in
the
next
slide.
We
describe
several
paths
you
which
we
should
be
included
in
this
fear:
young,
om,
OM,
young
tekmoto.
The
first
is
the
test:
appoint
a
locator
here
in
the
past,
appoint
a
locator.
We
list
the
straight
power
meters.
The
first
one
is
feed
stream
lands.
The
second
one
is
come
to
my
ID
and
the
last
one
is
PFR
impeach
forwarding
notoriety.
We
think.
Oh
nice
reconfirm
the
cast
pointer,
locator
and
next
slide.
I
Please
about
the
tours,
as
there
is
oval
group
dropped
about
the
beer
team
and
in
which
it
describes
the
king
I
simply
chose
as
the
bureau
em.
So
we
list
the
choice
of
your
item
key
here
and
the
next
I'm.
Sorry,
this
is
the
and
the
next.
The
next
slide
of
maybe
we'll
make
some
mistakes
about
this,
the
OEM
layer
which
it
has
with
the
young,
which
is
asked
with
the
OEM
young
model
on
the
authors.
I
I
The
next
slide
shows
and
the
next
slide
yeah
next
step,
and
this
is
a
newly
idea.
We
come
up
with
the
fear,
om
work,
so
we
want
to
ask
about
whether
it
is
ready
to
start
after
this
work,
because
now
we
can
see
there
are
many
related
work
for
good
jobs
such
as
the
lime,
young,
connectionless,
om,
the
pure
young
or
group
draft,
and
summon
it
and
many
others
overlay
om,
related
to
dress
yep,
hi.
J
K
I
Thank
you,
I
got
the
point
and
we
have
a
discussion
about
the
connection
list
and
connect
the
oranges
on
the
stage,
and
now
we
think
that
the
beer,
maybe
much
more
related
with
the
connection
place
and
the
incorrect,
has
another
idea
about
the
oranges,
some
oranges
or
with
maybe
some
stage
we
can
discuss
about
the
details
and
the
last
one
and
the
list,
but
not
the
the
last
one,
is
we
welcome
you
to
fulfill
this
work
together.
If
you
are
interested
in
that
next
slide,
maybe
that's
all
yeah
thanks
any
questions.
J
F
L
F
I
F
I
J
That
I'm
sorry,
okay,
Greg
your
ski.
So
yes,
there
are
several
ways
to
do
technology
specifics,
so
it
could
be
as
argumentum
beer
specifics
to
lime
model,
that's
one,
because
basically
what
at
least
for
it's
hard
to
say
to
speak
over
so
they
use
their
test
point,
location
and
characterization.
So
if
we
define,
if
we
define
test
point
in
a
beer
since
then
it
it
should
be.
C
J
F
J
J
J
M
I
D
G
J
It
so
I
just
want
to
present
you
an
update
of
work
that
we
are
now
planning
to
continue
at
and
do
a
three
group.
It
started
as
a
design
team
and
under
part,
the
gvg,
and
let's
go
this
next
slide.
So
what
was
objective?
There
are
effortless
to
have
some
common
OEM
mechanisms
and
in
structures
formats
that
can
be
reused
by
there
is
overlay
networks,
Viera.
J
J
J
Oam
message
has
some
flags
resort
filled
and
next
protocol
next
protocol
might
be
helpful
for
overlay
Network,
but
for
different
to
see
them
yeah,
and
we
have
proposed
optional
time
stamp
block
that
one
of
the
flags
indicates
presence
of
the
time
stamp
blog,
which
follows
immediately
overlay,
OEM
header,
as
we
found
it.
Some
applications
might
use
it
for
one
way
round
trip
measurements
and
it
supports
use
of
different
time
stamp
formats,
whether
it's
an
NTP
of
PTP
version
to
truncate.
J
J
Support
from
encapsulation
layer
that
really
cannot
be
fulfilled,
you
can
be
guaranteed
and
we
have.
A
lot
of
examples
are
to
that
in
our
some
networks
that
been
developed
earlier,
and
we
had
to
work
on,
compensating
that
with
example
and
mpls
with
introduction
of
gal
label
and
the
rule
that,
for
example,
special-purpose
labels
not
to
be
used
for
hashing
its
key.
J
So
what
we
point
to
the
designers
of
encapsulations
that,
even
though
there
is
a
practice
of
using
the
payload
to
control
and
use
equal
cost
multipath
environment,
it's
a
beneficial
to
have
generate
entropy
to
the
level
based
on
certain
rules
at
the
edge
and
then
in
their
domain
overlay.
The
main
to
use
entropy
label
value
for
ecmp
that
will
allow
use
the
same
value
for
active
OEM.
J
J
So
if
we
have
a
pure
active
OEM
case,
then
the
next
protocol
will
be
lets,
say,
0
or
actually
their
context
is
none
so
pointing
that
we
have
only
om
message
in
the
packet
and
that's
will
be
case
of
epic
poem
next
slide,
please,
but
we
have
a
lot
of
discussion
of
interest,
adding
on
some
point,
OEM
or
signaling
statistic,
telemetry
information
or
to
the
life
packet
that
can
be
achieved
with
the
overlay
OEM
header
as
well.
So
it's
just
uses
there
next
protocol
payload
to
indicate
the
payload
type
of
their
data
packet.
J
J
J
J
J
There
is
a
work
on
being
solution
being
proposed
in
the
34.
There
are
trace
route
and
transcending
trace
route.
There
are
some
different
scenarios
that
being
considered
because
we
have
overlay
and
we
have
underlay
transcending
tourist
route,
addresses
the
tracing
of
underlay
network.
But
there
are
scenarios
I
believe
in
beer.
We're
tracing
overlay
is
as
important
because
you
have
ingress
router,
you
have
transit
via
farce
and
then
you
have
egress
routers
and
then
they
might
have
ecmp
in
overlay
as
well.
J
D
Right,
gentlemen,
a
lot
has
a
question
mr.
address,
but
it
was
a
thread
going
on
about
this
particular
work
and
how
it
actually
is
not
taking
place
in
this
group,
but
he
has
a
responsibility
to
notify
all
the
groups
that
it
could
affect,
and
the
issue
is
you
put
up
a
15-minute
presentation
in
15,
different
working
groups
right
or
some
way
to
consolidate.
The
problem
is:
there's
nothing
structured
in
the
IETF
to
let
that
happen
right
I
mean
you
guys
need
to
know
about
it.
We
sent
the
list,
I
mean
I,
get
response.
D
F
J
J
J
G
F
Okay,
so
that's
just
an
update
that
the
code
points
have
been
cold
now,
so
Jeffrey
shot
the
stuff
off,
the
dough
will
be
going
base
to
iono
ospf
is
under
7120
arm.
So
that's
like
the
INR
earlier
location,
thingy
arm
and
we
need
three
values.
We
need
to
be
R
sub,
tlv,
mpls,
encapsulation
sub
theory,
which
is
really
a
sub
sub
field
in
the
treetops
subsea
FeLV.
Next
one
and
is,
is,
is
actually
under
expert
review.
Less
left
the
room
right
now,
it's
not
in
the
building.
So.
F
So
so
I'll
be
poking.
The
chairs
there
I
I,
think
they
have
three
experts
and
then
probably
we
advise
iono
as
well.
Armed
technically.
We
also
need
three
points
for
the
mpls
and
caps
are
we
need
for
the
Bering
for
and
their
sub
sub
povs,
which
is
the
mpls
and
kept
supplementary
car,
but
we
have
to
be
BSL
conversion,
which
is
optional
right
now
on
ice
ice,
which
is
missing
no
SPF.
F
N
F
Q
F
N
Q
N
Silly
comment
right:
we
didn't
when
we
made
these
with
recipes
for
quiet.
I
recall
the
proper
process
and
didn't
ask
for
any
suggested
values.
However,
if
it
just
happens
to
be
anybody
who
actually
feel
to
the
prototype
and
actually
uses
values
that
don't
come
from
the
experimental
space,
this
might
be
a
good
time
for
them
to
speak
up
and
the
hope
that
I
Anna
will
allocate
three
different
values.
Maybe
st.
Vitus,
yes,.
F
S
D
F
D
All
right
back
to
this
all
right
now
open
discussion
section
you
guys
are
fully
aware
that
we
have
a
charter.
It's
a
working
group
in
our
charter.
We're
told
that
this
work
is
experimental.
An
experimental
status
is
actually
dependent
upon
our
ability
to
prove
that
this
is
something
that
the
community
needs
as
a
whole.
It's
a
shift
in
the
in
addition
to
the
internet
architecture,
so
I
posted
this
just
the
text
right
from
the
Charter.
D
You
guys
can
pull
the
stuff
up
and
if
I
could
read
it
to
you
or
you
can
read
it
yourself,
but
I
want
to
highlight
some
key
points
in
this
that
are
part
of
our
decisions.
Moving
this
stuff
forward,
so
particular
sensitivity
of
adding
new,
significant
functionality
to
the
point
to
product
to
the
data
plan.
That's
really
what's
unique
about
what
we
were
doing
here.
If
you
look
at
the
current
internet
architecture,
we've
got
ipv4,
ipv6
and
pls,
and
now
we've
got
beer.
D
So
it's
at
that
point
in
the
hourglass
that
we're
asking
to
not
change
something
but
add
something
new
and
so
I
can
seed
your
thoughts,
but
I'd
rather
get
thoughts
from
the
room
first
and
have
a
really
open
discussion
about
this
stuff
in
the
Charter.
It
says:
look
at
item
nine
below
so
nine
brought
in
here.
Deployment
evaluation
seems
to
be
the
key
to
seeing.
So
we
can
look
at
this
and
say
this
makes
a
lot
of
sense.
What
does
it
really
happen
on
the
wire?
D
What
has
happened
in
hardware,
which
the
impact
the
architecture
of
the
boxes
as
well
as
the
Internet
at
large?
So
in
this
it
talks
about
deployment
experience
without
defining
what
deployment
experience
is
and
I've
had
some
discussion
with
folks
along
the
way
and
I
think
it's
it's
a
fair
assessment.
Well,
I,
take
it
back!
Yeah
I'll
put
it
out.
There
I
think
it's
a
fair
assessment
to
say
that
before
anyone
actually
puts
in
the
network,
they
beat
the
crap
out
of
it
in
their
labs
they're
supposed
to
do
that.
D
Operators
do
that
today
and
for
them
that's
an
adequate
test
point
before
it
actually
goes
into
a
live
network.
I
think
it's
fair
to
us
that
to
say
that
we're
not
going
to
ask
them
to
do
anything
more
than
than
what
they
currently
did
if
it
works
in
the
lab.
That
seems
to
me
to
be
an
deployment
experience
that
the
work
group
should
listen
to
and
take
that
forward
in
this
document.
This
description,
that's
in
here,
has
to
be
in
a
document
we
need
to
put
together.
D
So
what
I'm
going
to
do
today
is
an
open
discussion
and
then
get
some
volunteers
to
provide
some
input
into
putting
this
document
together.
So
what
I'm,
puttin
out,
there's
deployment
experience
I
think
should
qualify
as
real
implementations
in
someone's
operator
lab
somewhere,
where
they're
getting
real
traffic
like
conditions
in
a
network
that
they
totally
use
to
evaluate
any
code
or
our
product
or
feature
this
can
be
rolled
into
the
production
network,
so
would
have
thoughts
with
that
rejection
to
that
a
different
opinion.
D
D
T
T
I,
because
people
playing
the
labs
with
million
things
and
I
can
give
you
a
big
list
of
things
that
people
play
with
in
the
labs
that
never
saw
the
life
of
the
day
so
a
so.
There
was
a
reason
why
we
put
the
experimental
I
think
we
have
a
very
good
momentum
with
their
technology,
but
a
a
deployment
experience
and
talking
about
the
labs
again
will
help
us
to
get
to
remove
the
experimental,
but
as
such
is
a
step
forward,
but
not
sufficient.
D
Okay,
can
I
address
that
issue
because
what
we're
talking
about
a
little
bit
vague,
I
would
say
that
there
are
some
lab
work
that
would
be
considered
almost
toy
like
and
there
are
other
lab
implementations
that
are
actually
full
replications
of
the
production
network
with
actual
traffic
patterns.
Those
things
exist,
so
how
would
that
be
different
than
I
mean
if
I'm
an
operator
I'm
not
putting
that
into
my
network
until
I
beat
it
up
in
my
lab,
where
I
will
now
we're
asking
the
eye
teeth
to
do
more
than
that?
Oh.
T
D
Use
your
own
words
in
my
support.
You
said:
unless
you
are
willing
to
put
revenue
generating
traffic,
you
didn't
say
unless
you
are
putting
revenue,
Jerry
traffic,
so
if
I
tested
through
my
lab
and
I
know,
this
is
what
it's
done.
I
am
willing
to
do
it
with
revolutionary
traffic.
I've
met
that
requirement
already.
That's.
D
Look
I
mean
that's
the
point,
that's
why
you
have
a
lab
right
I.
Do
that
to
do
this
evaluation
before
I'm
going
to
go
ahead
and
make
that
jump,
and
if
we
have
an
operator,
that's
going
to
step
forward
and
said
I'm
ready
to
make
that
jump.
They've
already
done
that
evaluation
now
I
think
we
need
to.
We
can't
just
take
it
blindly.
We
need
to
look
at
the
work.
They've
done
the
extensive
amount
of
testing
they've
done
and
take
that
all
into
consideration.
D
T
T
D
I'm,
looking
for
a
precedence
and
I
haven't
found
one
right,
we're
talking
this
the
14
plane
here.
What
was
the
president's
to
adopt
ipv4?
I
know
I'm
honest,
I
mean
that's
that's
where
we
are
in
the
hourglass,
I'm
not
I'm
not
trying
to
just
be
facetious.
I
mean
this
is
real.
Now
right,
so
I
I
don't
want
to
have
to
set
precedence
with
it,
I'd
like
to
reference,
something
that
we
have
and
what
we
have
is
texture.
D
T
D
I
wouldn't
say
it's
hard
and
fast
year,
but
there's
a
bit
of
a
chicken
and
egg
that
goes
with
this
as
well.
Right
and-
and
you
know,
if
we
put,
we
put
it
in
movable
object
and
it's
going
to
be
a
little
tough.
However,
one
of
the
options
and
maybe
take
a
sense
of
the
room
is
we
could
probably
move
this
all
the
way
to
RFC
under
experimental
much
quicker,
but
does
that
really
serve
our
purpose?
D
Is
it
worth
going
through
the
work
and
and
and
making
this
effort
to
ensure
we
get
on
the
standards
track,
take
a
little
extra
time
and
do
what
I
think
is
important
for
the
overall
net
architecture
rather
than
push
it
through?
So
let's
get
a
sense
of
the
room.
First,
that's,
okay!
So
okay,
who
thinks
it's
worth
the
effort
to
try
to
get
this
work
shifted
to
the
standards
track.
D
Who
would
rather
see
us
just
push
this
through
and
keep
it
experimental,
Wow?
Okay,
so
four
to
12,
15
ish,
so
Sanders
track
is
kind
of
winning
on
the
volume
there
we'll
take
it
the
list
to
get
some
feedback.
So
in
our
charter
we
have,
it
didn't,
say
no
option.
It
gave
us
the
option,
move
this
up
forward.
So
I'd
say
that
is
work
that
has
already
been
accepted
to
be
adopted
by
the
working
group.
We
can
move
that
forward.
D
Q
K
A
Q
Q
With
the
current
charter,
that
would
mean
that,
for
instance,
this
number
9
having
a
document
which
would
be
acceptable
to
the
other
ID
to
the
rest
of
the
isg,
for
a
solid
reason
to
make
the
change.
I
would
also
like
to
point
out
the
existence
that
we
now
have
status
change
mechanism
so
that
it's
possible
to
take
a
document
which
is
informational
or
experimental
or
proposed
standard,
and
simply
do
a
status
change
to
change
it
from
experimental
to
proposed
standard
or
in
facto
standard
to
internet
standard
it
doesn't
require.
Q
D
I'd
say
we
have
that
process.
It's
not
completely
flushed
out.
We
have
a
process
here
as
well
working
them
in
Paris.
Here
we
go
so
I
ads
from
our
vote
count.
It
sounds
like
we
have
enough
interest
at
least
work
on
this
document
to
make
our
case
that
sound,
reasonable
I
mean
for
those
who
would
like
to
push
it
forward.
Faster
I
mean
this.
Doesn't
stop
that
I
mean
we're
still
going
to
progress,
but
at
least,
if
nothing
more,
that
being
skeptical
is
good.
D
Q
Is
also
now
for
other
purposes,
but
it
might
be
interesting
here.
The
waiting
for
implementation
status
for
documents
where
you
take
them
house
working
for
glass,
call
and
determine
consensus
and
get
them
into
really
solid
shape,
and
then,
if
it
sits
waiting
for
implementation,
which
in
this
case
might
be
implementation
and
deployment
that
would
at
least
be
a
way
of
indicating
the
documents
are
fairly
close
to
done,
and
we
could
also
get
some
of
the
Directorate
reviews
done
ahead
of
time.
S
Ice
so
I
guess
you
have
to
get
a
little
more
free
bed
made
from
the
operators
right
if
they
have
any
issues
with
something
being
experimental.
Putting
in
your
network
or
SUV
is
kind
of
strike.
That's
it
from
an
architecture
when
you
do
with.
If
we
did
our
jump
well,
then
it
doesn't
be
change.
Anything
like
is
more
processed
at
this.
We
go,
but
operators
speak
up.
Alright.
D
U
N
Yeah,
I
mean,
I
don't
think
aggravated
a
good
point,
but
to
be
the
really
issue
is.
Is,
though,
why
we
wanted
to
extra
work
to
make
it
standard
rather
than
experimental
I
mean
what
difference?
Does
it
make?
It's
just
a
matter
of
politics
of
the
base.
Documents
have
been
sitting
around
for
three
years
with,
maybe
in
one
case
it
was
K
into
the
interim.
Mostly
they
haven't
changed
March
the
editors
are
likely
to
die
of
old
age
before
the
things
that
come
on
ROC.
N
V
Martin
Hana
far
from
the
tea,
has
been
the
question
for
operator
feedback.
It's
fine
here,
well
long
story,
short,
I.
Think
this
question
doesn't
really
matter
too
much.
So
what
matters
for
us
most
is
running
code
next
is
we
have
the
document
we
can
refer
to
so
I'm
having
an
RFC
rather
than
a
verbal
document
would
definitely
be
a
plus
the
document,
of
course,
always
being
better
than
anything
else.
So,
but
you
are
also
right,
Greg,
their
own
apt
and
their
labs.
V
Whatever
is
in
our
level,
my
left
specific
is
usually
quite
close
to
being
actually
deployed
in
a
very
big
network,
and
anything
that
is
going
to
be
deployed
in
our
network
is
going
through
this
lab.
So
that
is
something
different
than
left.
In
many
cases,
that's
true
in
general,
I
would
say
yes,
this
is
work
that
belongs
on
this
turn
attract,
but
if
there's
serious
difficulties
or
delay
I,
don't
really
care.
J
C
O
O
F
To
operate
already,
let
me
let
me
chime
in
here
so
I
like
hands
going
down,
and
obviously
we
had
a
lot
of
hands
going
up.
15
people
when
it
is
informational,
RFC
to
be
worked
on
pointing
up.
You
know
the
application
of
the
technology
experience
and
so
on.
So
these
15
people,
if
they
care
about
getting
the
stuff
on
the
standards
track
rather
than
just
popping
a
hand
up,
should
basically
start
to
crank
this
RFC
and
I.
S
O
95%
the
plan
nine
ten
percenter
has
to
be
signed.
In
fact,
it
won't
be
firm,
yeah,
no
yeah.
You
know
what
yeah
yeah
so
there's
other
options
right
now,
right,
I
don't
have
to
deploy
this
because
I've
got
otherwise,
but
if
I
a
standard
and
the
option
is
clear
and
it
brings
benefit
to
the
business
than
output,
but
if
I'm
deploying
it
just
for
the
fun
of
it
and
it's
my
energy
but
I
have
other
options
today.
O
P
Okay,
Roberta
gundark,
so
from
the
perspective
of
deployment
in
enterprise
network,
what
really
matters
is
when
we
deploy
experimental
and
then
it
switches
to
the
standards
track
our
eye
on
a
conference
going
to
be
reallocated
or
they
always
stay
the
same,
even
if
they
are
from
different
pool
right,
because
if
there
is
no
change
in
implementation,
I
don't
think
it
matters
which
way
what
matters
is
actually
in
tableau
implementing.
So
as
long
as
the
spec
stays
intact,
specification,
wise
I,
don't.
T
Q
The
ionic
code
points
wouldn't
change,
as
I
was
saying
if
the
documents
were
issued
as
experimental
rfcs,
and
then
we
had
a
draft
that
explained
the
benefits
and
so
on,
enter
experience
with
it
and
wanted
to
go
to
standards
track.
That
could
be
as
simple
as
a
status
update
to
the
document
to
change
it
from
experimental
to
standards
to
proposed
standard.
Q
When
we
had
the
ball,
there
were
obviously
the
nice
technology.
A
lot
of
progress
has
been
made
on
the
document
since
then
as
well,
but
we
couldn't
quantify
some
of
the
benefits
that
would
drive
towards
deployment
and
if
you
look
at
the
Charter
text,
which
is
somewhat
hard
to
read
from
here,
then
you'll
see
that
the
question
is
sort
of
what
are
the
benefits?
What's
our
experience
in
the
trade-offs,
can
you
quantify
it
in
a
way
that
justifies
it
and
bluntly?
Does
it
actually
solve
your
problems
right.
D
So
this
has
actually
been
pretty
enlightening
to
thank
you
that
it
looks
like
we
have
really
there's
no
hard
requirement
to
change
the
Charter
direction
before
these
documents
get
published.
We
can
take
the
stuff
forward
and
in
the
experimental
track,
and
in
parallel
those
who've
you
raise
their
hands
I'll
reach
on
the
email
list.
We
can
start
working
on
this
document,
which
will
be
needed
in
either
case
to
move
this
work
into
consideration
forward
to
make
that
vision
into
the
center
track.
D
D
So
this
was
the
fall
out
here.
I
mean
we
can.
We
can
beat
this
up
in
the
room
a
bit
more.
What's
our
time
was
here
actually
we're
doing
great
and
you
guys
are
dying
to
spend
more
time
talking
about
beer
right.
Look
at
that
nods
and
grins
I
see
smiling
face
the
first
time
that
all
so
we
went
to
come
up
with
this.
D
In
particular,
the
analysis
of
the
impact
and
benefits
of
new
beard
airplane
to
the
overall
in
an
architecture
would
specifically
talking
about
that
choke
point
like
what
is
this
benefit
and
I've
been
stewed
I
mean
it's
obvious
from
those
that's
been
banging
on
multicast
along
it
up
and
see
the
Delta
right.
But
what
hit
me
is
that
I
would
say:
IP
multicast
was
a
mistake.
I'm
going
to
throw
it
out
there
using
the
IP
header
to
represent
multiple
endpoints
requiring
n2n
flow
state
across
the
internet
is
a
pretty
broken
idea
right.
D
Finally,
we
came
to
a
point
where
maturity
internet
is
is
grown
to
where
we
have
our
networks,
as
well
as
our
internet
responsibilities
and
within
our
networks
me
make
decisions
that
are
end-to-end
within
our
network
and
not,
and
an
host
a
host
and
beer
was
a
chance
to
came
out
of
the
chance
of
looking
at
that
and
say
what
do
I
want
with
them.
I
topology.
That
gives
me
the
utility
replication
without
this
flow
based
requirement.
So
I
think
you
know
in
this
discussion.
D
That's
that's
at
least
if
I
were
to
write
this
now
that's
kind
of
direction.
I
would
take
that
we're
fixing
a
thirty-year-old
mistake
right,
we're
providing
a
set
of
tools.
Now
that
makes
unicast
replicate
with
the
same
simplicity,
the
same
will.
Let
you
guys
use
this
phrase.
I
call
it
deterministic
convergence.
Something
is
totally
unique
to
those
of
us
in
bangin
on
both
the
cast
long
enough
right.
D
You
do
something
in
your
lab
and
it
looks
great
and
you
roll
it
out
in
deployment
and
as
more
and
more
people
use
that
service
the
performance
degrades
because
the
flow
state
begins
to
explode
inside
the
network.
That
is
no
longer
a
condition
in
Bureau.
It's
a
radical
shift
in
how
things
are
done
inside
that
network.
So
it's
it's
actually.
D
In
the
same
way,
people
I
won't
mention
technologies,
but
the
look
of
technology
say:
what's
your
multicast
solution
for
that,
under
the
assumption
that
replications
something
you
could
bolt
onto
any
technology
after
the
fact
and
get
that
sort
of
utility
those
around
long
enough
know
that
it's
not
trivial
and
it
should
be
part
of
the
architecture
from
the
beginning,
and
so
what
this
is
doing
is
really
giving
a
toolset
that
allows
replication
in
a
very
inexpensive
and
lightweight
way.
That
has
been
unique
in
terms
of
what
we've
done
in
there
and
architecture
in
the
past.
L
M
D
So
going
back
to
the
show
of
hands
those
well
yeah
I
won't
limit
the
input
who
is
willing
to
assist
putting
this
document
together,
Wow
even
in
one
of
the
naysayers.
Thank
you
that
your
input
it
be
important,
I
appreciate
it
I'm
a
little
disappointed
as
many
hands
came
up
so
yeah.
Let's
move
it
forward,
but
we've
got
at
least
three
now
I'll.
Take
it
to
list
as
well,
and
we
can
start.
You
know
an
ad
hoc
discussion
and
start
flushing.
D
D
S
A
small
loss
comment
about
the
architecture
and
the
mpls
or
the
encapsulation
dog,
so
we
didn't
present
here
this
time
because
they
were
very
little
changes
to
that.
So
all
the
changes
made
to
the
cancellation
documents
we
you
know
presented
on
four
hands.
So
that's
why
we
didn't
present
it
this
time.
Yeah
I
think
we're
all
pretty
much.
You
see
a.
U
Yeah,
and
just
just
one
final
comment:
one
of
your
concerns
is
the
chicken
and
egg.
You
need
to
play
min
to
prove
deployment
to
get
to
this
next
step,
and
so
what
I
would
I
would
kind
of
suggests
that
if
this
is
useful,
people
are
going
to
play,
whether,
regardless
of
its
label,
if
its
standards
track
or
if
it's
experimental,
if
it's
useful,
it'll
get
used,
so
it
shouldn't,
you
know,
cause
you
to
prematurely
move
it
to
a
different
category,
because
that'll
make
it
get
used.
D
D
All
right
anything
else,
great
discussion.
Thank
you
very
much
and
I'll
see
you
all
on
the
list.
We
have
a
piece
of
work
to
adopt.
We
have
requests
for
feedback
and
input
to
that
that
migration
doc
and
then
we
have
moving
some
of
these
mature
docs
forward
into
requests
for
publishing.
Last
call
all.