►
From YouTube: IETF99-PALS-20170717-1740
Description
PALS meeting session at IETF99
2017/07/17 1740
https://datatracker.ietf.org/meeting/99/proceedings/
A
B
B
So
this
is
the
pal
session
in
ITF
99.
This
is
actually
the
first
pal
session
that
we've
had
in
a
few
iet
s,
because
most
of
the
work
we've
been
doing
over
the
email
lists
anyway,
I'm
animales.
This
is
Stuart
Bryant
right
here.
We
and
we
have
Davidson
Duke
roped
in
the
first
row,
who
is
our
working
group
secretary
and
David,
has
kindly
volunteered
to
to
take
our
notes.
This
is
the
note.
Well
I
would
like
you
to
note
that
this
is
a
new
note.
Well,
it's
not
the
same
now.
D
B
B
Ok,
there
were
blue
sheets
going
around
we're
the
blue
sheets.
Currently,
ok,
could
you
please
start
the
blue
sheets
or
keep
or
continue
the
blue
sheets.
B
We
have
two
more
drafts
that
will
be
published
soon
that
are
currently
on
the
RSC
editors
queue,
the
PAL
status
reduction
and
VPLS
Pam
snooping.
We
have
two
more
with
Deborah
right
now
in
IES,
you
review
pals
status
reduction
and
Pete
MP
pseudo
wire,
LSB,
pink
one
is
currently
out
for
expert
review
and
the
other
is
waiting
for
ad
follow-up
and
that's
it
for
our
draft
right
now.
We
have
no
other
working
group
drafts.
However,
that
said
we
do
have
two
individual
drafts
on
today's
agenda.
B
That
may
become
working
group
drafts
and
there
may
be
at
least
one.
There
may
be
a
pals
draft
resulting
from
work
in
the
debt
networking
group,
where
this
may
be
a
debt
net
draft.
That's
currently
under
discussion
with
the
folks
in
the
debt
networking
group
for
those
of
you
who
have
not
been
following
debt
net
you
might
want
to.
If
you
have
an
interest
in
SU
the
wires
that
this
is
just
little
editorial
comment.
B
Debt
net
is
doing
some
extremely
interesting
work
on
deterministic
networking
and
one
of
the
portions
of
the
solution
that
they're
that
they're
discussing
in
the
currently
and
the
debt.
Networking
group
is
the
creation
of,
what's
being
called
a
debt
net
pseudo
wire
and
and
so
it's
it's
work.
That's
of
interest
to
the
folks
here.
So,
if
you've
not
yet
been
following
debt
net,
you
may
wish
to
anyway.
E
D
A
D
Next
slide,
please
so
the
ietf
either
the
Palin's
working
group.
Well,
the
Kiwi
working
group.
In
fact,
when
I
took
a
decision
when
how
Souter
wise
were
first
deployed
that
some
equipment
of
commercial
importance
was
unable
to
support
the
Ethernet
control
word,
and
so
we
would
allow
an
option
where
Ethernet
pseudo
wires
could
run
without
it.
D
At
that
time
there
were
no
Ethernet
MAC
addresses
issued
by
I
Triple
E
that
started
with
0
X,
4
or
0
X
6
Pat
tells
me
that
there
were
that
there
may
have
been
some
others
that
I
didn't
understand,
but
certainly
0,
X,
4
and
0
X
6
were
not
officially
allowed,
and
so
it
was
considered.
It
was
safe
to
deploy
Ethernet
pseudo
wires
without
the
control
word
then.
Hence
the
drafts,
the
RFC
saying
that
the
control
word
for
the
ethernet
pseudo,
where
I
would
be
optional.
D
So
next,
please
so
what's
happened
since
well.
The
I
Triple
E
rack
has
issued
Ethernet
addresses,
started
with
4
or
6
right.
I
think
they've
gone
from
a
sort
of
linear
policy
to
a
kind
of
a
random
policy.
As
what
was
said
to
me
and
because
presumably
the
others
are
depleted,
there's
an
even
higher
chance
of
getting
a
0,
a
4
or
a
6.
D
Presumably
the
the
non-force
or
some
non-force
or
6
are
depleted,
and
so,
if
right
behind
right
anyway,
this
makes
the
initial
assumption
that
there
could
be
no
confusion
between
an
ethernet
packet
without
CW
and
an
I
control
word
and
an
IP
packet
invalid.
Now,
though,
it's
actually
been
in
Valley
for
quite
some
time.
It's
just
that.
We
didn't
really
talk
about
it
very
much.
Obviously,
none
of
the
vendors
really
spoke
about
it,
so
carry
on
yeah.
F
G
D
D
Of
time
right,
so
the
important
thing
is
that
our
assumption
was
has
been
invalid.
Well,
it
was
invalid
at
the
time
and
has
subsequently
been
seriously
invalidated
due
to
a
changing
policies.
So
it's
what
some
equipment
was
doing
was
through
implement
some
complex
proprietary
methods
to
try
and
figure
out
whether
it
was
an
IP
packet
or
a
pseudo
aia
packet,
and
they
rely
on
the
heuristics
and
or
they
unreliable
the
point
of
view.
So
operators
have
been
seeing
packet,
Mis
ordering
and
drops
in
the
network.
D
I'll
explain
why,
in
a
moment
and
they've
expressed
some
concern
to
us
next
slide,
please.
So
why
does
the
MIS
ordering
happen?
Well,
it
happens
in
ecmp
situations
where
what
people
were
trying
to
do
is
to
load
balance
their
pseudo
wire
over
a
bunch
of
different
circuits
in
the
in
the
wine
and
what
they
would
do
is
they
would
look
below
the
MPLS
label
stack
which
you're
not
supposed
to
do,
but
they
would
look
there.
D
They
would
say
AHA,
it
starts
with
the
four
or
it
starts
with
a
six,
and
so
it
must
be
an
IP
packet
and
then
proceed
accordingly
and
they
would
try
and
low
balance
on
the
five
couple,
which
of
course,
might
not
be
anything
of
relevance.
In
fact,
it
could
be
a
sort
of
a
random
field
in
the
protocol,
depending
on
whatever
the
protocol
was
the
next
slide.
Please,
why
is
it
a
problem?
D
B
D
Next
slide,
please
well.
The
control
word
was
always
designed
to
prevent
this
problem
by
putting
a
zero
in
the
first
nibble.
Zero
cannot
be
a
four
or
a
six,
and
what
we've
done
is
effectively
hijacked
IP
version
zero,
which
was
an
interesting
discussion
at
the
time.
So
we
hijacked
zero.
We
hijacked
one
I,
think
beer
is
hijacking
to
on
me
mm-hmm,
so
we've
been
stealing
IP
version,
numbers
and
I
wonder
when
someone's
going
to
complain,
I
suppose
well,
actually
the.
D
B
D
I
mean
the
point:
is
that
they
that
I
suppose
they
might
have
been
needed
for
something
like
defining
a
new
IP
version
at
some
stage
and
anyway
we
have
been
stealing
them
version.
Zero
is
probably
never
deployable
as
an
IP
version,
and
it's
how
we
distinguish
between
a
pseudo
wire
and
anything
else.
D
D
So
if
it's
impossible
to
mandate
it,
then
we
can
only
start
the
migration
process.
So
the
next
slide,
please.
So
what
we?
What
we,
the
the
key
piece
of
text
in
the
draft,
is
the
text
in
blue.
That's
on
this
slide,
which
that
we
is
that
we
update
RFC
four
four
four:
eight,
which
is
the
Ethernet
encapsulation
design,
to
state
that
when
the
ingress
PA
and
the
egress
PA
support
the
ethernet
controller
pseudo,
our
control
word,
then
the
control
word
must
be
used.
When
we
go
to
the
next
slide.
D
Look
at
a
question
for
you,
I
said:
must
there
the
I'd
originally
intended
to
say
recommended?
Hence
the
title
of
the
draft,
but
we
as
a
working
group
need
to
decide
which
of
these
we're
going
to
say.
Do
we
say
must
or
do
we
just
say,
recommend
it?
That's
a
question
for
the
people
presence,
otherwise,
I'll
toss
a
dice.
G
E
D
It
still
says,
but
when
both
the
ingress
and
the
egress
PA
support
the
ethernet
control
wire,
then
we
either
say
it's
muscle:
it's
recommended
that
the
control
won't
be
used,
though.
So,
if
you,
if
you
don't
support
it,
then
you're
not
bound
by
the
prefix
of
this
a
of
this
sentence
and
okay.
So
you
and.
D
D
H
As
a
comment
on
this
about
equipment,
when
this
problem
started
to
appear
that
basically
the
platform's
which
had
no
support
for
control,
were
to
be
dominant
at
the
time
the
average
lifetime
of
a
platform
in
the
field
is
five
six
years
and
most
of
those
platforms
which
did
not
support
it
at
the
time
they
are
long
gone
today.
Virtually
everything
that
supports,
so
the
bias
is
able
to
support
control
what
it's
not
a
problem
anymore.
H
Certainly
you
will
be
able
to
find
all
the
platforms
in
the
field
that
make
an
exception
for
this,
but
basically
the
playing
field
has
changed,
as
it
was
an
exception
to
find
the
platform
which
had
support
for
pseudo
I
in
say
in
2008
timeframe.
Now
it's
an
exception
to
find
a
platform
which
does
not
support
control.
What
first
of
the
wire
so.
D
Do
I
add
that
so
this
this
covers
all
the
cases
is
technique.
That
was
all
of
the
cases
right
you
you.
If
you
find
yourself
with
one
of
those
pieces
of
equipment,
you
can
still
deploy
it.
You,
if
you
find
yourself
with
and
in
a
situation
where
you've
got
control
word
available
with
the
text
currently
says
you
must
use
it.
D
H
Probably
a
question
for
the
market
too,
and
it
will
that
equipment
will
be
phased.
Naturally
it
would
simply
die
off
and
therefore
my
personal
vote
would
be
for.
Must
yes
stating
the
exceptions
which
you
have
in
our
coming
slides?
Yes,
that
there
might
be
cases
where
it
is
not
possible
or
it
might
break
thing
break
things,
but
overall
you
must
use
it
when
it
is
available.
Okay,
okay,.
F
F
F
G
Siena
so
sorry,
I'm
late,
I
didn't
get
to
the
previous
slides
and
all
that.
But
since
I
guess
you
are
asking
the
working
whether
to
for
the
language
right,
yeah
and
I
have
I
used.
The
word
I
would
I
would
like
the
word
recommended.
Rather
than
must
and
I
think
we've
gone
through
this
before
right
and
there
was
a
lot
of
the
operators
game.
There
were
I,
think
ndu
wrote
a
draft
or
an
RFC
that
talks
about.
G
D
Ridership
that
the
text
says
it,
but
the
ingress
and
the
egress
supports
it,
and
then
you
must
use
the
control
word
if
ingress
or
and
or
egress
do
not
support
it.
You
are
still
compliant
with
the
with
the
RFC.
The
the
context
of
the
previous
discussion
was
OAM,
where
we
were
going
to
try,
we
were
going
to
try
and
you
know,
make
the
OAM
only
operate
in
a
control
word
context,
so
that
would
have
invalidated
those
platforms.
This
doesn't
invalidate
those
plans,
I,
don't.
G
Know
whether
they
do
is
just
the
OEM
I
think
it
was.
The
whole
reason
for
using
the
control
word
was
that
all
the
CMP
was
getting
screwed
up
because
of
the
MAC
address,
starting
with
the
four
right
and
the
so
that
was
the
driving
factor
at
that
time,
as
well
as
om
yeah.
People
wanted
to
use
the
control
word
as
the
channel
one,
but
I
think
even
here,
the
as
far
as
the
language
is
concerned,
not
both,
but
at
least
any
either,
if
any
one
of
them
right.
D
Yeah
you
shouldn't
yeah
right
so
web,
where
both
support
it.
It
says
you
must
use
the
physical
feature,
that's
what
we
are
proposing
right.
If
either
you
know
the
the
unwritten
text
is,
if
either
don't,
then
you
just
ignore
the
rest
of
the
document,
so
we
don't
invalidate
the
deployed
base
that
can't
do
it,
although,
as
Ignace
was
just
saying
that
deploy
base
is
getting
smaller
and
smaller
by
the
week.
G
Everything
is
with
the
advent
of
a
VPN.
Yes,
you
know,
there's
a
less
traction
with
the
l2
VPN
and
the
solo
wire
and
all
that
stuff,
but
for
the
so
I
guess
this
is
okay,
but
you
know
I
think
I
would
just
leave
it
alone.
People
know
the
importance
of
having
to
use
the
control
word.
So,
okay
leave
I.
Doubt.
I
Some
persons,
I
think
mandating,
makes
a
difference.
I
think
it's
important
for
the
IETF
to
be
clear
that
this
protocol
must
be
used
in
a
way
such
that
it
does
not
invalidate
the
significant
MAC
address
space.
Okay
and
to
me,
you
must
say,
must
okay
on
the
first
point,
I
know
on
the
second
point
on
equipment
that
does
not
support
this
I.
Think.
In
addition,
you
need
to
you
need
to
add
to
the
document
that
equipment
is
that
does
not
support.
I
This
is
not
recommended
or
or
something
so
I
think
you
need
to
say
that
or
if
you
don't
want
to
say
it's
not
recommended
or
that
it's
broken,
then
you
need
to
say
that
in
that
it
will
cause
significant
problems,
because
it
invalidates
part
of
the
MAC
address
space
and
you're,
not
going
to
know
what
pieces
you're
going
to
get,
and
you
might
want
to
do
special
stuff
like
you
were
talking
about
before.
But
you
know
that's
a
kludge,
Ryan
and
I
wouldn't
recommend
cluding.
So
would.
I
H
I
D
H
Next,
so
a
comment
about
the
operators
being
aware
of
this:
they
are
surprisingly
unaware
of
this
problem.
This
problem
surfaces
periodically
in
various
operations
mailing
lists
and
it's
always
the
same
story.
My
new
shiny
route
is
dropping
packets.
What's
wrong,
oh
I
just
deployed
this
new
to
the
wire
based
architecture
and
I
get
random
drops.
B
G
F
G
D
G
I
mean
that
III
would
I
would
dispute
that
that
you
you,
you
cannot
put
a
language
like
that
in
an
RFC,
because
that's
not
what
the
idea
I
mean
there.
You
can
say
this
is
how
each
it
is.
This
is
recommended
or
the
language
that
you've
used
here.
But
beyond
that
going
and
saying.
Well,
you
should
face
this
out
or
you
should
just
use
this
core
router
or
something
like
that.
That's
not
the
place
for
the
IETF
RFC's
or
something
like
that.
Dave.
E
My
only
point
it
yeah
so
as
far
as
the
language
goes,
we
can
craft
some
of
the
language
so
that
it's
perhaps
a
little
gentler
and
say
that
you
know
equipment
that
does
support
this.
You
know
it's
strongly
recommended
that
equipment
be
upgraded,
I,
support
it
or
enhanced
to
support
it
if
not
necessarily
replaced,
and
if
we
insist
on
the
replacement
language
I
can
go,
buy
shares
in
a
forklift
commerce.
C
C
C
C
J
Speaking,
we
definitely
want
in
our
documents
to
be
very
clear
when
there
are
when
we
have
identified
problems
with
using
something
I
mean
it's
just
says
it's
there,
pointing
out
the
security
consideration.
Section
is
now
in
our
documents
where
you
have
to
be
very
verbose
to
say
if
there's
problems
identified-
and
you
know
we
should
be
doing
this
in
a
constrained
environment,
because
it's
our
responsibility
to
inform
users
of
our
specifications
with
the
problems
one.
This
is
a
definitely
an
identified
problem.
Yeah.
G
I
So
I
think
it's
necessary
to
have
some
warning
in
here.
I
mean
the
point
that
operators
may
not
be
aware
of
it.
I
think
it
needs
to
be
makes
their.
That
was
the
the
indication
when
the
when
the
rack
was
made
aware
of
this,
because
an
operator
had
complained
to
the
rack
about
the
that
the
rack
had
a
problem
by
assigning
numbers
being
with
the
four
or
six,
because
their
router
now
didn't
work.
So
it
was
the
I
Triple
E
problem.
Well,
it's
not
the
I
Tripoli's
problem
I
mean
right.
I
G
You
know
this
internet-based
services,
pseudo
Weiss,
has
been
humming
for
a
long
long
time,
so
that
one
Operator
coming
and
complaining
at
the
I
Triple
E
about
address
assignment
I.
Think
now
to
tell
you
the
truth.
I
think
this
problem,
probably
the
the
routers,
don't
even
do
the
five
topple
based
on
the
the
the
end
of
say,
end
of
label.
What
end.
F
G
Stack
level
thing
I
think
there
is
a
fair
to
the
wire.
There
is
an
entropy
level.
There
is
a
lot
of
things
that
are
already
there,
so
this
notion
that
okay,
the
end
of
stack
label
with
the
fighter,
which,
let's
do
a
CMP
on
that,
so
those
routers
are
also
going
away,
but
anyway,
I
I
strongly
disagree
that
we
should
put
a
in
any
any
language
about
not
using
those
equipments
or
anything
like
that
noted.
D
Okay,
so,
but
there
is
a
downside
to
this
as
Ignace
that
pointed
out
to
me
last
night,
the
first
and
the
first
one
is
obvious.
I
didn't
really
thought
is
that
the
packet
gets
four
bytes
bigger
part,
that's
bigger,
and
there
our
deployments
where
the
MTU
size
is
tightly
constrained
and
those
deployments
would
have
a
problem
with
the
inclusion
of
the
control
word.
It
seems
to
me
that
they
might
be
better
off
fixing
their
MTU
problem
than
after
trying
to
figure
out
why
they're
losing
random
packets
in
the
network.
D
There
are
also
middle
boxes,
apparently
that
analyzes
pseudo
wire
traffic
without
first
analyzing,
the
signaling,
or
maybe
they
don't
seen
the
signaling
and
they
make
assumptions
about
the
packet
format
and
they
work
on
the
assumption.
There's
no
control
word
and
they're
just
not
going
to
hack
this.
D
D
That's
Matthew
Bakke,
who
was
a
former
P
with
him
each
year,
so
then
I
think
I'd
like
with
the
start
the
formal
adoption
process
immediately
after
this
meeting,
it's
my
view,
as
as
both
an
author
and
an
experienced
chair,
that
the
draft
is
perfectly
acceptable
to
come
under
working
group
control
and
as
an
editor
I
will
obey
the
consensus
of
the
working
group.
So
I
think
the
right
thing
to
do
is
to
adopt
it
that
sends
an
important
message
to
our
colleagues
in
the
I
Triple
E
that
we're
taking
the
problem
seriously.
D
Ideally,
I'd
like
this
to
be
with
the
iesg
by
Singapore.
So
maybe
we
could
try
for
a
for
a
record
in
the
working
group
yeah
why
the
rush
a
number
of
operators
have
raised
this
problem
with
us.
The
I
Triple
E
liaison,
has
raised
it
with
the
isg.
Our
ad
has
asked
us
to
fix
the
problem.
The
problem,
the
fix,
is
relatively
simple:
there
spend
more
time
discussing
the
context
and
the
limitations
than
we
will
the
solution,
and
so
I
think
we
should
do
it.
D
E
D
K
K
K
K
Yeah
and
also
we
defined
in
interface,
node
and
name
and
image
you
be
known
today
in
the
face,
Noda
and
also
too.
This
is
the
way,
a
parameter
and
also
the
humanization
type.
We
define
gdm,
afar
and
idiom,
so
so
under
the
procedure,
no
wild
type.
We
support
the
RTP
Priscilla
and
sabbatical
proceed
well
or
for
the
multi
settlement
interpreter
well
defined
the
name
and
that's
a
personalized
segment,
a
and
C.
So
this
is
the
tree
structure
or
draft.
G
So,
however,
common
this
Himanshu
from
Siena,
so
this
is
all
almost
all
of
it-
is
covered
in
the
l2
VPN
yang
data
model.
I
mean
this.
There
is
a
lot
of
overlap
here.
The
part
the
mostly
we
have
concentrated
with
Ethernet
pseudo
wire
in
l2,
VPN
yang
model,
the
and
the
multi
segment
part
is
not
there,
but
you
know,
many
of
these
other
attributes
are
all
covered,
and
now
pseudo
white
is
a
separate
container.
B
F
K
B
K
B
K
D
G
I
didn't
yet
yeah
I'm
the
author
of
del
to
VP,
there's
a
whole
group
of
people
that
are
working
on
the
l2
VPN
yang
model
in
the
best
working
group,
and
just
recently,
we
forked
out
the
pseudo
wire
separate
container
and
I
have
all
this
almost
all
of
this
information
in
there
now
the
parts
that
are
missing
is
like
I
said
we
we
are.
We
were
concentrating
more
on
the
Ethernet,
but
the
pseudo
wire
types
like
ATM
and
primarily
and
those
can
be
easily
added
and
the
multi
segments
were
wire
art.