►
From YouTube: IETF93-SOFTWIRE-20150720-1740
Description
SOFTWIRE meeting session at IETF93
2015/07/20 1740
A
C
A
So
for
our
working
group
documenta,
we
submitted
a
quite
a
few
of
were
documented,
who
is
GN
them
laser
fire
document
has
been
having
put
it
into
the
arms
eid
to
you
and
the
young
author
48th
state
Hester.
So
this
is
a
lateral
for
six
and
four
RT.
Don't
approve
mentor
for
the
authors
and
we
also
need
the
author
approve
enter
for
map
map,
dear
safety
and
the
maps
here.
A
D
D
So
hopefully
everyone
is
in
the
room
should
have
a
fairly
good
idea
of
what
a
software
is.
The
idea
wasn't,
as
the
main
software
drafts
were
going
through
the
the
approval
phase
in
the
iesg
review.
One
of
the
comments
that
was
raised
by
the
ops
area
was
that
there
was
no
mechanism
for
managing
leads,
so
this
was
one
of
the
drivers
for
producing
a
yang
model
to
deal
with
that.
D
So
with
that
question
we
collected
or
from
discussion
with
the
work
group,
we've
tried
to
make
a
comprehensive
yang
model
which
is
going
to
cover
all
of
the
standards
track,
software
draft,
so
all
of
the
the
ones
that
are
currently
just
just
waiting
for
publication.
So
that's
sir
wait
for
over
6,
mapi
and
Matty
yeah
I
won't
dwell
too
much
on
the
architecture,
hopefully
everyone's
fairly
familiar
with
that
stuff.
Next
slide,
please
so
structurally,
the
model
has
well
three
submodels
that
sit
inside
there.
D
We
structured-
we
put
it
together
with
using
lightweight
for
over
6
1,
dividing
that
into
a
the
CPU
portion,
the
the
beef
for
portion
and
the
aft.
Our
is
the
software
tunnel
concentrator.
It
just
made
sense
because
there
wasn't
enough
commonality
between
the
two
of
them
with
mapi
and
map
t,
because
there's
a
common
set
of
rules
and
a
common
format
for
those
rules
that
are
used
for
both
the
CP
and
for
the
concentrator.
We
could
use
a
single
model
and
we
use
that
in
both
cases.
D
So,
but
we
took
the
the
approach
of
taking
mapi
and
Matty
and
separating
those
out
as
well,
it
is
possible
that
we
could
get
greater
reuse
of
the
way
the
mechanism
is
by
or
the
way
that
the
model
is
by
combining
those
further,
but
for
clarity,
I
think
it
works
better.
This
way
as
it
stands
at
the
moment,
next
slide
please.
D
So
this
was
lost
presented
at
91.
That
was
whether
a
quest
came
to
extend
this
and
unmaking
include
all
of
the
standards
tracks,
one
so
maps
he
has
been
added
since
then.
The
division
of
lightweight
for
over
16
to
be
fore
and
aft
are
as
new
some
comfort
example
configuration
stuff
has
gone
into
there.
We've
extended
it
with
a
notification
model
as
well
from
discussion
in
an
ietf
91.
The
decision
was
not
to
include
a
nap
configuration
model
in
there,
which
I
think
is
still
the
right
answer.
D
Although
you
know,
if
one
does
appear
from
somewhere
I'm
not
aware
of
anyone
working
on
one,
but
if
one
does
appear
from
somewhere,
then
it
would
be
good
to
have
that
so
that
we
could
at
least
reference
it.
We've
also
added
some
traffic
stat
counters
in
there
as
well
and
security
considerations.
Next
slide,
please.
D
The
documents
also
been
through
a
young,
a
young
doctor.
Doctors
review
23
comments
back
in
total
they're,
all
included
at
the
end
of
here.
If
anyone's
interested
in
importing
through
the
my
one
or
you
were
the
mini
tale
of
them,
but
most
of
them
are
around
consistency,
grammar
and
so
forth.
There
was
a
few
more
substantive
ones,
given
the
the
way
that
this
sort
of
divides
out
into
three
natural
models
in
there
is
this
one
model
or
is
it
three?
D
B
You
know
and
I
just
had
a
comment
right,
so
we
don't
know
if
this
is
gonna
stay
in
the
same
structure
if
it
gets
adopted
by
the
working
group
right.
So
so
another
way
of
looking
at
it,
like
you
said
that
you
considered
is
like
combining
the
common
stuff
together
from
all
the
three
mechanisms
right.
So
the
way
like
we
did
the
DHC
options
right.
We
there's
like
theoretically
a
possibility
of
doing
the
same
way
with
these
things.
Joe
right
so
I
think
it's
a
bit
premature
to
decide
on
that.
D
B
D
Comment
number
12
is
around
adding
tunnel
oam
BFD
being
the
specific
suggestive
way
of
doing
this,
so
it
was
a
suggestion
that
we
should
consider
it.
We
did
consider
this
and
what
well
the
consensus
that
we
came
back
with
was
that
it
wasn't
a
particularly
good
idea.
I
mean
with
with
the
software
implementations,
we've
really
shied
away
for
keeping
from
keeping
/
tunneled
state
and
in
any
kind
of
additional
signaling
around
there
and
Tunnel
OEM.
You
know.
Bfd
would
add
that
to
the
that
overhead,
which
I
don't
think
is
a
particularly
desirable
thing.
D
There
was
a
draft
I
seem
to
remember.
Tina
sue
had
around
BFD
signaling
for
soft
wires.
I
forget
what
happened
with
that.
Exactly
I
would,
if
that's
necessary,
and
if
that
was
to
progress
than
I,
would
suggest
that
the
yang
model
gets
augmented
to
be
able
to
support
that
common
220,
fmr
BMR
rule
definition.
Originally
we
had
this
set
up
as
a
new
and
enumeration
type
for
fmr
or
BMR
I.
Don't
think
the
comment
was
well,
the
comment
said
is
thinking
about
this
and
I.
Think
we've
described
that
incorrectly.
D
It
should
be
a
BMR
boolean
on
there,
which
describes
whether
the
rule
is
suitable
for
uses
of
BMR
rather
than
hard
coding.
Kind
of
this
is
what
the
rule
is,
because
obviously
fmr
is
something
sorry.
Bmr
is
something
which
will
be
identified
by
the
hostess
part
of
the
configuration
so
in
the
next
update
will
make
that
change
yeah
and,
as
I
mentioned,
that
the
complete
sets
at
the
end
of
the
this
presentation,
if
you
really
want
to
go
through
it
right.
So
this
is
a
quick
overview
of
the
new
stuff
around
the
notify.
D
The
net
conf
notify
model
which
would
allow
you
to
have
a
sort
of
publish
and
subscribe
way
of
making
changes
towards
the
particularly
towards
a
software
concentrator,
for
example,
so
that
is
new
in
there
next
slide.
Please-
and
this
is
just
a
breakout
of
what
a
an
example
configuration
renders
this
XML
for
a
martin,
lib
netconf,
and
I
think
that's
just
about
their
next
slide-
please
ok,
so
yeah!
This
is
a
third
review
of
the
document.
We've
been
through
the
the
yang
dr.
in
process-
and
you
know
this
is
I.
D
B
F
F
It
is
also
it
it
also
adopts
the
same
encoding
as
ITF
software
multicast
the
prefix
option-
and
this
is
the
working
group
document
this
attribute-
can
be
used
in
in
various
contexts
such
as
multicast,
dslite,
multicast,
light
with
us
for
over
6,
nappy,
mft
and
so
on,
and
include
other
ipv4
to
ipv6
interconnexion.
The
internet
working
techniques.
F
This
is
the
scenario
of
the
solution:
mp4,
once
mp4
sent
dhcpv6
the
receipt
to
NASA
NASA
will
send
radios
message,
access
request
to
23
a
server
and
then
three
years
/
reply
access
access
except
include
multicast,
the
prefix
64
to
mass.
This
is
the
main
and
very
simple
process
of
the
radios
process.
Next
slide:
how
about
the
deployment
on
software?
Magic?
Has
the
transition
already
tested
and
it
deployed
in
orange,
and
there
are
some
real
requirements
from
china
telecom
and
there
are
some
updated
updates.
F
F
6333
and
chapter
ITF
SoftWIRE
map,
I've,
c59,
69
and
also
the
multicast,
is
dslite
and
mesh
multicast
get
recipe
option
d'etre
of
the
sccp
options
are
the
companion
documents
of
the
primary
documents
and
they
are
also
adopt
as
a
also
be
adopted
as
a
working
group
document
or
AFC,
and
the
radius
options
are
the
same
with
the
HTTP
options.
There
is
the
path
chapter
who
SoftWIRE
matic
has
radius
extension
is
the
only
shaft
that
not
has
been
adopted
so
next
next,
shall
we
atop
the
document
as
a
working
group
title.
B
Few
people
thing
is
like
this
thing
requires
a
recharter
so
like
we'll
have
the
discussion
at
the
end
and
and
if
we
decide
to
reach
out
there,
we
will
consider
like
one
item
at
a
time
right.
So
at
this
point,
we're
not
able
to
adopt
so
like
I,
don't
want
to
do
the
call
now,
but
once
we
finish
the
recharter,
if
there
is
interest,
like
you
say,
from
the
operators,
we
will
certainly
consider
okay.
G
Oh
say:
Here
I
am
okay,
my
name
is
HSN
kya
I'm,
going
to
talk
about
multicast,
support
for
map
and
lightweight
for
over
6
next
slide,
yeah,
so
keys
and
Carlene
I
think
the
only
multicast
support
craft
software
has
this
light
now,
but
this
site
has
developed
many
other
transition
protocols
and
most
important
ones
are
map
and
and
night
wait
for
our
six.
So.
G
G
So
in
in
this
one,
I
show
on
pictorially
of
translation.
Multicast
would
work
with
Matt
pan
and
so
basically
the
IP
for
multicast
user.
That
could
be
previous
issues,
but
that
we
assume
ipv6
network
supports
up.
You
know
cast
natively,
so
I
24,
multicast
user
has
problem,
so
we
need
to
translate
it
whatever
they
might
be,
for
users
sends
or
receives
into
ipv6
multicast,
so
the
so.
G
The
group
management
messages
which
need
to
be
trusted
into
MLD
and
then
multicast
data
to
ipv6
now
and
the
other
side
map
we
are
both
router
does
the
reverse
translation
so
is
because
it's
connected
to
ipv4
network.
So
it
can
know
it
acts
like
a
IGM
MLG
toys,
MP
translator
and
IP
for
network
site,
igmp
or
team
browser,
and
so
none
so
as
result.
Well,
the
on
this
side
and
I
p43
is,
must
cast
regenerated
and
then
on
the
ipv6,
Network,
ipv6
3
is
generated
so
and
then
they're.
Basically
these
points
they
are
combined.
G
So
we
come
to
the
users.
It
is
seen
as
a
single
three
now
and
then
the
non
ipv4
multicast
source
is
able
to
send
a
multicast
later
to
their
multicast
users
in
the
home
network,
for
example:
ok,
I,
guess:
that's
it
yeah
now
lots
of
details,
then
we
need
to
you
need
to
do.
We
have
it
in
the
draft
and
so
those
interested
I
think
I
you're
welcome
to
read
all
details
and
if
you
have
any
questions
post
them
quick
list
in
light-weight
for
over
six.
G
G
So
and
some
advising
windows
and
I
decided
to
grant
that
comment
llegando,
so
we
obtained
on
the
translation,
multicast
yeah,
that's
it
no
I,
guess
yeah
discuss
what
can
be
done
with
this
Rafton
I
I
believe
it.
It
is
important
and
we
need
to
progress
this
trap
to
someone
that
emotional,
you
summarize
so
I
will
leave
it
to
the
chairs.
That's
there.
B
So
thanks,
I
said
so.
I
think
it's
got
a
I'm
gonna
give
you
the
same
answer.
I
gave
to
way
before
right
like
so,
we
don't
know
like
who
wants
this
okay,
so
we
don't
want
to
do
stuff
that
nobody
wants
at
this
fine
like
we
are
nearing
the
like
life
of
the
working
group
right
so
like
we
are
almost
ready
to
close,
so
we
are
not
going
to
take
up
stuff
and
that's
not
essential.
Okay.
B
So
let's
try
to
figure
out
like
what's
the
essential
stuff
left
and
if
there
is
a
need
for
stuff,
we
will
take
it
out,
but
ok,
because
it's
like
there's
like
effort
to
spin
up
a
new
working
group
and
doing
stuff.
So
if
it's
like
small
things
that
there
are
obvious
bugs
or
something
that's
obviously
missing,
so
it
meets
a
deployment
demand.
We're
gonna
go
for
it,
otherwise
we're
just
gonna
close
yeah
right.
So.
G
I,
what
encourages
me
is
this
map,
I
think,
is
one
of
the
most
important
protocols
that
developed
and
a
lot
of
operators
was
ready.
We
saw
in
the
many
ways
so
I'm
supporting
so
eventually
they're
going
to
meet
some
some
multicast
in
a
map
network
and
nitrate
04
/
6
is
an
improved
version
of
TS
light,
so
I
mean
I'm
hopeful
that
just
something
like
this
I
must
approach
this
green
in
it.
Okay,
thanks
bye,
sir,
thank
you
need
to
solace
it
to
the
operator
that
we
need,
and
they
should
say,
tell
us
that.
B
Okay,
so
we
come
to
the
point
of
the
meeting,
so
software,
like
has
been
quite
successful.
We
managed
to
get
like
a
lot
of
documents
through
and
the
stateless
document
said
is
currently
at
the
RFC
editor
q,
like
it's
not
48,
so
most
of
them
are
going
to
be
published
in
the
next
few
days.
Dot
48
took
longer
than
48
hours,
as
it
usually
does
it's
almost
at
three
weeks,
but
there's
been
vacations
and
stuff
like
that.
B
Like
the
chairs,
we
had
a
discussion
between
the
last
meeting
in
this
one
and
we
want
to
do
a
graceful
share
on
instead
of
like
just
throwing
the
scope
of
the
group
and
just
keep
taking
on
new
things
like
we
want
to
slowly
ramp
it
down
and
like
close
pretty
quickly.
So
that's
kind
of
the
strategy
so
Kenny
sure
the
proposed
milestones
we
put
together.
Some
proposed
milestones
for
how
we're
going
to
get
the
things
through.
B
It
looks
pretty
aggressive,
but
it's
not
because
a
lot
of
the
drafts
are
like
pretty
mature
and
they've
been
held
back,
unfortunately,
because
of
all
the
activity
on
the
stateless
solutions
right.
So
we
spent
like
most
of
the
working
group
energy
on
the
stateless
solution.
So
like
we
didn't
get
like
much
reviews,
we
didn't
get
much
air
time
or
any
time
on
these
documents,
so
they're,
just
like
they
got
like
pretty
well
reviewed
and
I
think
they
should
be
able
to
go
out
of
the
working
group
pretty
quickly.
B
B
Because
last
time
we
visited
the
unified
CP,
like
people
are
just
freaking
out
right,
like
everybody
had
their
own
idea,
how
to
do
things,
and
this
could
potentially
take
longer
and
one
question
I
want
to
put
before
the
group
is,
that
is
there.
Somebody
who
still
wants
it
I
know
en
is
gonna,
say
yes
right,
but
we're
trying
to
figure
out
it.
B
Is
it
worth
spending
that
energy
like
to
finish
it
off,
because
I
know
there's
like
a
lot
of
work,
that's
been
put
onto
it,
but
the
question
is:
do
we
continue
to
put
energy
on
it?
Because
the
draft
is
currently
expired
right,
so
it
takes
up
effort
to
pull
the
things
up
and
maybe
find
additional
editors
like,
because
I
know
there's
like
two
people
who
stopped
coming
right
like
so,
we
need
to
probably
find
more
blood
to
do
it.
D
So
in
Ferrara,
I'm
can
I
just
a
clarification
question.
First,
when
the
operational
documents
that
you're
referring
to
they
are
these.
The
same
operational
documents
have
been
discussed
in
v6
ops,
so
the
summer
of
the
fred
baker
has
is
kicking
off
there
and
you
know,
is
asking
for
what
operational
experience
of
deployments
around
this.
So.
B
They
are
design
at
this
point
by
the
question
they're
disjoint
at
this
point,
okay,
but
the
question
is
the
first
question
is
like:
are
we
going
to
do
stuff
here
or
not
that
that
would
be
like
one
question
we
gonna
find
out
because
fred
and
I
had
like
an
young,
we
had
a
chat
offline
with
the
80s
like
saying
like:
where
should
this
go?
She
is
this
like
an
operational
document
or
not,
and
I
don't
think
we
managed
to
have
a
conclusion
there,
but
the
question
is:
do
you
want
these
documents?
That's
the
first
question.
B
You'll
figure
out
the
venue
later,
because
if
we
figure
out
is
gonna
be
done
in
v6
ops,
it's
still
probably
gonna
get
a
last
call
here
in
addition,
because,
like
the
expertise
for
software
is
here
right
so
but
but
still
the
question
is:
do
we
need
these
documents?
What
technologies
do
we
cover
because
that's
something
we
kind
of
danced
iran
right
like
we
don't
know
that
somebody's
gonna
say
I
need
for
rd
deployment
right.
Do
we
do
it?
Do
we
not
do
it
right.
D
Now
it's
very
common
I
mean
Fred
did
to
quite
a
lot
of
work
on
scoping.
What
what
should
be
the
contents
of
their
and
I
think
I
think
there's
already
a
mapi
one,
that's
been
published,
all
I
haven't,
I,
haven't,
read
it
yet,
but
some
yeah
I
thought
they're
starting
to
you,
know,
get
some
kind
of
formats
and
some
kind
of
shape
around
there.
D
D
Regarding
the
unified
cpe,
so
I
mean
I,
don't
know
whether
the
unified
CP
is
still
the
right
Monica
for
it.
Recently,
we've
done
a
fair
amount
of
work
around
taking
the
open,
wrt
implementation
of
this
and
testing
it
in
our
environments,
and
we
have
situations
where
we're
running
deer
slight.
We
have
situations
where
we
running
light
weight
for
over
six.
We
need
to
swap
between
those
modes
within
within
the
light
cycle.
D
D
Oh,
you
know,
I
think
there
is
a
prioritization
rule
that
was
put
in
to
that
particular
implementation,
just
to
say,
stateless
transition,
better
than
stateful
transition,
and-
and
so
that's
the
value
that
it
has,
which
is
which
is
ok,
but
that
what
what
it
doesn't
seem
to
be
able
to
do
is
change.
It
makes
up
his
mind
it's
a
reboot
so
right.
So
this
is
stuff
that
I
think
you
know
now
that
we're
actually
getting
to
the
stage
where
we've
got
deployments
out
there.
D
You
know
the
bits
that
haven't
been
quite
or
the
loose
ends
that
haven't
been
tied
up
are
starting
to
matter
and
unified.
Cp
is
certainly
one
of
those
there's
another
draft
which
I've
got
in
there,
which
is
not
listed
on
here,
which
is
about
multiple
tunnel
endpoints,
which
is
more
driven
about
differences
between
how
implementers
have
chosen
to
build
the
AFT
are
and
again
I
mean
looking
back
at
the
the
lightweight
spec.
You
know
it's
not
something
that
we
explicitly
covered
in
there.
So.
B
D
D
B
So
sorry
for
the
people
who
are
remote
like
this
is
just
something
we
are
showing
here,
but
we
haven't
put
it
in
the
proceedings,
but
we
got.
The
idea
is
like
we
will
like
submit
like
a
new
charter
stuff
after
we
talked
to
ad
on
the
list
right
along
with
proposed
milestones
to
like
to
the
working
group
for
discussion.
So
there's
like
something
like
the
chairs
have
been
sitting
together
and
doing
like
to
kind
of
clean
it
up
a
bit
and-
and
you
will
get
a
chance
to
comment
ian
for
sure
on
that
right.
B
D
B
I
F
B
So
if
you
look
at
this
rate,
we
are
asking
for
new
stuff,
so
you
would
obviously
say
something
and
better
to
say
something
when
we
propose
this
new
charter
right,
you're,
gonna,
come
back
and
say:
hey
I
want
this
thing
added,
and
then
we
discuss
it
on
the
list
and
see
if
it
needs
to
get
a
delay.
That's
the
plan,
so
we
are
proposing
some
stuff
based
on
what
we
see
already.
But
this
is
a
presentation
from
you
today.
B
So
when
we
send
out
this
charter
proposal,
you're
free
to
comment
at
the
time
and
say
like
this
is
something
we
need.
This
is
like
china
telecom's
flying
to
apply
it
and
soon
Jung
may
come
back
and
say
yes
like
we
want
to
do
it
right
and
then
we
proceeded
to
see
if
you
want
to
add
it
or
not,
based
on
consensus.
Okay,
you
understand
the
process
or
kept
things.
C
C
It
concerns
me
that
there
are
a
large
number
of
items
there
that
need
to
get
through
and
I'm
worried
about
the
amount
of
people
in
the
working
group
who
are
going
to
be
able
to
contribute
to
that.
It's
nice
to
say:
hey
I'd,
like
this
widget
X.
Unless
there's
a
body
of
people
that
are
keen
on
working
on
widget
X
it
it
makes,
you
know
it
makes
it
difficult
to
call
consensus
yeah.
So
please.
B
Keep
that
in
mind,
so
just
to
answer
that
there's
probably
going
to
be
four
documents
that
are
new.
Most
of
the
other
documents
are
documents
that
we
held
back
as
on
the
instruction
from
the
ad
to
help
hold
other
things
back
other
than
the
software
solutions.
So
some
of
these
things
are
just
like
stuff
that
has
been
reviewed
last
called
already
and
like.
We
also
went
to
the
move
doctors
for
early
review
so,
like
all
these
things
have
been
widely
revered
right.
So
it's
the
working
groups.
Job
is
done.
B
Right
so
out
of
here,
so
the
yang
model,
the
deployment
models
and
the
unified
CPR,
the
stuff
that
are
that
require
significant
review
and
those
are
the
things
we
are
questioning,
whether
we
need
them
or
not.
Right,
like
that's
what
we're
going
to
question
so
other
than
that,
like
it's
all
stuff,
that's
mostly
been
done
already.
I.
C
Would
then
urge
you
to
make
that
specific
call
on
the
mailing
list
asking?
Is
there
a
body
of
people
who
are
willing
to
spend
time
on
on
those
those
items?
Okay
and
I
think
that
will
give
you
a
strong
indication
as
whether
to
either
continue
or
call
those
documents
is
dead
and
close.
The
working
group
perfect
thank.
B
G
J
B
It's
good
to
know
like
so
when
we
asked
for
the
comments
on
this
like
feel
free
to
make
the
comment
right
length
and
so
I
think.
One
thing
we
need
to
know
is
like
we
need
to
have
people
who
can
review
the
document
because,
like
we
don't
want
to
take
up
a
document
where
we
get
like
one
review
during
work
in
the
class
call
out
none
right.
B
So
we
need
to
be
able
to
do
that
and
if
you
probably
need
to
get
somebody
with
multicast
knowledge
to
take
a
look
at
it
and
comment
on
it
right
like
so
there's
like
set
of
stuff
to
do
like
we
can
just
pick
up
the
document,
but
if
we
don't
have
the
energy
in
the
working
group
to
finish
it,
we
don't
want
to
take
it.
It's
just
the
chairs
call
right.
So
we
had
like
a
long,
tough
right
in
this
working
group
like
we
spend
a
lot
of
energy
in
getting
the
stateless
documents
out.
Okay.
B
So
if
we
don't,
we
may
not
have
the
energy
to
finish
all
the
documents.
We
don't
want
to
take
them
up
that.
That's
our
thinking,
okay,
but
make
the
comment
like
when
we
send
out
the
Charter
for
review
and
the
milestones
say
like
I
want
this
to
be
added,
and
this
is
why
I
need
it:
okay,
okay,
thank
you.
Thanks.
B
B
That's
it
so
thanks
a
lot
folks,
so
we'll
send
out
the
chatter
for
review
like
within
the
next
couple
of
weeks
until
you're
gonna
get
a
bunch
of
documents
in
the
next
two
weeks
as
well,
and
we
really
apologize
for
the
people.
Who're
got
the
documents
waiting
because
of
the
stateless
documents.
It's
it's
unfortunate,
but
thanks
a
lot
for
your
patience
thanks
a
lot
and
have
a
nice
evening
or
if
you
have
another
meeting,
have
a
nice
meeting.