►
From YouTube: IETF106-SPRING-20191118-1000
Description
SPRING meeting session at IETF106
2019/11/18 1000
https://datatracker.ietf.org/meeting/106/proceedings/
A
This
is
the
note
well
given
that
we're
Monday
morning,
then
maybe
you
haven't
seen
it
already.
If
you
haven't
seen
already,
please
read
through
it
and
if
not,
if
you
have
please
be
aware
of
it,
please
note
it
well,
we
have
a
shipping's
going
to
help
us
with
the
minutes
and
I.
Think
if
you
case
any
would
as
well
if
we
could
do
with
the
jabber
scribe,
though,
if
anybody
would
like
to
volunteer
for
that.
A
Since
I'm
being
quiet,
I
know
it
might
be
a
shock
and
I'm
being
quiet.
Okay,
the
minutes
can
be
collaborative.
The
etherpad
is
linked
here
because
it's
got
an
ipv4
literal
in
the
URL
there.
It
links
to
you
now,
rather
than
etherpad,
iit
after
dog,
so
you
can
find
it
either
linked
from
the
slides
that
we
uploaded
or
in
the
minutes
did
we
have
any
volunteers
for
a
Java
subscribe.
A
A
So
we're
gonna
be
blocked
on
continuing
the
meeting
to
get
to
by
having
somebody
to
do
this,
please
because
it's
kind
of
important
to
allow
remote
participants
to
be
able
to
collaborate
with
us
here,
and
this
is
one
of
the
ways
that
people
ask
questions
so
it
would
be.
I
can
do
have
anybody
who
has
a
jabber
client,
that's
willing
to
to
relay
questions.
Please.
A
Okay,
Martin's
made
some
noises
so
we'll
assume
that
that's
able
to
be
enough,
I'll,
try
and
jump
on
as
well
and
one
small
update,
but
has
been
exceptionally
useful
for
helping
burn,
I
pull
together
this
meeting,
and
we
now
have
a
secretary.
Thank
you
very
much
shipping
for
your
your
efforts
here.
She
has
immensely
helped
us
build
the
materials
and
the
agenda
together
for
this
meeting.
So
thank
you
very
much
indeed.
A
A
So
some
updates
about
the
working
group
in
general.
There
is
this
large
cluster
of
documents
see
with
3:40.
That's
in
the
RFC
editors
queue
we
are,
the
majority
of
them
are
now
in
all
48
and
they
include
some
of
the.
You
know
pretty
key
documents
that
we've
had
we've
had
for
a
while,
including
those
that
sort
of
initiated
spring.
A
So
some
of
the
work
like
the
the
MPLS
draft
and
then
the
IGP
extensions,
our
support
the
base
sr
functionality
there
now,
all
in
the
RFC
editors,
q,
I,
think
there's
essentially
a
lot
of
these
are
linked
together
and
blocked
on
the
same
documents.
So
once
Earth's
48
is
done
on
all
of
these
and
there
I
think
there's
only
the
epe
that
might
be
the
epen
ones,
which
are
both
IDR
drafts
and
maybe
the
beach
pls
one
that'll
have
other
reference
dependencies.
A
But
once
this
is
done,
then
we'll
be
done
with
the
you
know:
the
kind
of
key
SR
MPLS
documents
being
standardized,
which
is
an
awesome
milestone
for
that
for
the
working
group
and
something
that
I
know
where
folks
have
been
involved
it
for
the
last
three
or
four
years.
So
I
think,
hopefully
next
time
when
were
in
Vancouver,
we'll
be
able
to
to
have
all
these
RFC
numbers
baked
in
and
to
take
a
little
time
to
congratulate
the
working
group
on
having
standardized
SR
MPLS.
A
Finally,
we
have
a
number
of
active
working
group
drafts,
some
of
which
that
we've
adopted
since
the
last
meeting
the
to
service
programming
and
nsh
documents
have
been
have
been
adopted.
Since
then,
we
then
have
the
past
segments
work,
the
work
on
SR
policy
and
the
work
on
the
yang
model
that
continued
to
be
kind
of
progressed
and
living
working
group
documents
and
then
the
SI
v6
network
programming
draft,
which
we
have
an
update
on
today.
A
So
coming
on
to
the
large
amount
of
discussion
that
we've
had
on
the
mailing
list
since
the
last
meeting
first
off.
Thank
you
for
the
active
discussion,
it's
good
to
see
that
their
mailing
list
continues
to
be
to
be
useful,
I
think
for
a
few
meetings
we've
before
before
this
we've
had
fairly
quiet
time
on
the
mailing
list.
So
it's
good
to
see
that
we
had
some
active
discussion.
The
discussion
there,
Bruno
and
I
and
and
and
Bruno
just
discussed
with
Martha.
A
We
wanted
to
sort
of
take,
take
some
takeaways
from
that
discussion
and
I
think
we
continue
to
have
some
consensus
around
si
v6.
Both
operators
and
vendors
have
are
interested
in
the
way
that
using
si
v6
in
its
current
form,
and
there
was
kind
of
no
strong
indicators
that
this
isn't
something
that
we
should
progress.
So
what
we'd
like
to
do
is
to
continue
to
progress
this
work,
especially
it's
you
know
it's
been
it's
been
work.
A
That's
been
progressing
in
this
working
group
for
a
number
of
a
number
of
years,
and
there
was,
though,
some
interest
to
look
at
active,
reducing
their
header
size
for
use,
cases
that
need
many
SIDS,
and
both
operators
and
vendors
within
the
working
group
showed
showed
some
interest
there.
Our
observations
are
there.
Several
solutions
for
that
on
the
table
and
there's
at
least
six
works
at
micro
side
work
that
we
heard
about
in
the
last
meeting
about
the
examples
of
that.
A
But
what
we
kind
of
felt
was
the
ahead
of
time
of,
like
choosing
between
those
those
different
documents
and
and
looking
at
the
the
way
that
we
want
to
progress
this,
this
kind
of
specific
use
case.
Then
we
need
to
be
explicit
about
what
the
goals
and
the
costs
of
each
of
those
proposals
are.
So
the
what
we
were
inviting
authors
to
do
is
to
be
explicit
and
explicit
on
both
of
these
things
with
their
documents.
So
we
can.
A
Whilst
these
documents
continue
to
evolve,
you
know,
as
as
individual
drafts,
we're
kind
of
clear
what
the
benefits
and
the
costs
of
each
of
them,
and
now
our
a
real
push
here
is
that,
let's
is
to
try
and
complete
the
si
v6
work
that
we
have,
that
we've
engaged
with
six
men
on
the
the
working
groups
been
working
on
and
use
the
learnings
there
to
try
and
guide
some
of
these
future
decisions
as
to
what
the
next
steps
after
that
to
maybe
address
some
of
these
large
assets.
That
should
be
pretty
high.
A
I
think,
if
we
block
all
they
block
any
solution
on
having
the
best
solution,
then
the
ITF
would
never
iterate
on
anything
right.
So
they
I
think.
The
problem
is
that
there
are
folks
that
III
I
mean
it
was
pretty
clear
across
the
comments
and
on
the
mailing
list
that
their
folks
are
using
this
this
technology.
A
So
it's
not
unusable
if
we
publish
it
so
it
kind
of
feels
like
it's
a
reasonable
thing
to
say:
hey,
let's,
let's
make
sure
that
the
bits
that
we
are
standardizing
and
that
I
think
we
should
be
open
to
saying
there's
parts
of
the
si
v6
solution
that
we
don't
need
to
standardize
right
now,
because
they're
not
key,
and
then
we
have
a
stake
in
the
ground
for
a
solution
one
and
then
we
start
looking
at
solution
two.
Otherwise
we
might
block
solution
two
on
solution,
three
and
henceforth
forever
I
guess.
B
I
wasn't
saying
block
anything.
I
was
saying
more
like
get
a
little
past
little
further
down
the
path
of
what's
right
and
what's
wrong
about
the
current
approach
and
what
are
the
things
we
want
to
fix
and
if
we
then
say
the
current
approach
is
fine,
then
go
ahead
with
that,
but
the
idea
that
we
complete
this
and
use
the
learning
from
this
to
inform
the
rest
is
fine,
but
I
think
we
could
actually
go
a
little
further
down
the
path
of
doing
that
and
I.
A
Think
I
think
absolutely
should
continue
to
examine.
These
are
the
bits
of
work,
I
think
what
we're
just
saying
is
that
spring
the
what
we'd
like
to
do
is
that
the
chairs
and
the
and
the
ATF
spring
is
to
allow
that
to
happen,
not
necessarily
in
the
framework
of
them
being
working
group
drafts.
Okay,
all
right
thanks.
C
Darren
Dukes
from
Cisco
I'm,
just
to
reiterate
that
what
you
said
there
there
are
a
lot
of
deployments.
I
mean
that
this
stuff
is
deployed.
It's
working,
it's
functional,
it's
implemented,
multiple
vendors,
the
standardization
of
it
by
this
working
group
is
seems
to
be
obvious
at
this
point.
Press
RB,
six.
D
My
concern
with
this
approach
on
that
last
bullet
point
is
that
you
end
up
creating
a
potential
situation
where
some
work
is
potentially
hostage
to
other
work,
because
it
effectively
says
that
if
you
want
to
advance
other
work,
you
have
to
agree
to
advance
this
first
and
effectively
rubber
stamp
it
because
by
not
doing
that
and
stalling
this,
because
you
don't
fundamentally
agree
with
something
in
it.
You
end
up
in
a
situation
where
you
are
preventing
advancement
of
your
own
work
by
standing
in
opposition
to
something
that
you
don't
agree
with.
D
It
creates
a
very,
very
difficult
situation.
If
a
draft
is
out
there
where
you
have
a
problem
with
it,
but
you
know
that
you
want
to
advance
something
else,
but
to
advance
the
other
thing.
You
have
to
shut
up
and
be
silent,
because
you
know
that
it's
not
going
to
proceed
in
the
context
of
the
working
group
until
the
other
one
is
finalized.
That
is
problematic.
D
A
Problem
I
think
I'd
like
to
make
an
observation
here:
sov
six
is
not
new
right.
It's
not
it's,
not
something!
That's
that
is
landing
in
the
working
group
now
and
we're
reviewing
today.
It's
something
that
there
has
been
consensus
of
this
working
group
to
adopt
and
that's
how
this
you
know
the
ITF
process
works.
We
work
through
consensus,
so
and
consensus
will
necessarily
consensus,
doesn't
say
absolute
agreement
from
everybody.
A
It
says
you
know
rough
consensus,
and
here
we
have
rough
consensus
from
what
we
can
tell
we
had
at
the
time,
and
it
doesn't
seem
like
the
the
mood
in
the
room
is
that
there
isn't
consensus
for
us.
Every
six
I
understand
that
there's
other
solutions
they're
being
proposed,
but
it
seems
like
there's
a
rough
consensus
and
running
code.
So
at
this
point
I
think
it's
very
difficult
to
argue
that
we
shouldn't
we
shouldn't
progress
it
now
to
move
on
to
the
point:
if
is
this
blocking
other
work?
A
I,
don't
think
it
has
to
be
I.
Think
we're
saying
here
that
the
like,
if
you
look
at
how
SR,
mpls
and
sov
six.
Actually,
let's
just
talk
about
sur
MPLS,
because
it's
less
controversial,
SRM
pls
progressed
outside
of
having
a
working
group
that
was
the
adopter,
adopted
it
and
had
a
running
code
way
before
that
time
and
this
it
didn't
stop
that
solution
progressing
right
and
at
the
time
that
SR
MPLS
was
was
in
opposition
to
RSVP,
and
we
had
the
same
kind
of
discussion.
A
E
Tinky
shot
from
future
well,
I
just
want
to
make
a
comment
that
the
IETF
works
on
certain
principles
and
processes,
and
one
of
those
processes
is
that
a
working
group
would
work
based
on
the
Charter.
And
if
you
look
at
the
current
spring
Charter
in
the
very
first
sentence,
it
says
that
this
working
group
is
there
to
work
on
SR,
MPLS
and
SR
v6.
That's
the
first
point.
E
The
second
point
is
the
very
next
paragraph
says
that
we
should
not
be
working
on
anything
that
is
incompatible
in
the
data
plane,
with
the
existing
solutions
that
we're
working
on
and
clearly
some
of
these
other
solutions
are
not
compatible
with
SR
v6.
So
can
we
just
follow
the
process
and
if
other
work
wants
to
be
done,
use
the
right
IETF
process
go
get
at
your
own
working
group
change
the
Charter
do
whatever
it
is.
You
need
to
do,
but
please
don't
bypass
the
process.
C
We
have.
We
have
an
architecture,
we
have
a
lot
of
maturity.
If
these
other
solutions,
you
know
want
to
progress
at
the
very
least,
they
need
to
define
why
they
are
better
and
why
this
working
group
should
be
interested
in
them,
and
that
should
happen
in
some
sort
of
separate
document
right
now.
There's
no
there's
no
justification
for
these
other
solutions
that
are
that
are
kind
of
floating
out
there.
Besides
with
the
working
groups
currently
chartered
for
so
I,
think
the
authors
of
those
things
need
to
seriously
consider
building
that
documentation
to
justify
their
work.
C
A
Think
that's
true
of
all
proposals
right.
It's
not
just
true
of
alternative
proposals
is
its.
It
should
be
true
of
amendments
to
existing
proposals
and
I
think
we
should
also
remember
that
the
documents
that
we've
adopted
as
the
working
group
are
not
individually
owned,
anymore,
right,
they're
owned
by
the
working
group,
so
things
that
go
into
working
group
documents
should
be
by
consensus
of
the
working
group,
not
by
consensus
of
the
authors
as
the
way.
If
that
work,
Ron
sorry,
okay,.
F
A
Full
time
I
think
if
you
look
at
the
agendas
over
the
last
ni,
etf's
I
think
the
majority
powerful
time
is
not
occupied
by
working
group
drafts,
and
so
absolutely
we
are
have
been
giving
individual
drafts
time
in
the
working
group
and
I
would
see
that
if
there's,
if
it's
of
relevance
to
spring
then,
and
especially,
if
there's
discussion
of
them
on
the
mailing
list,
then
that
would
be
it's
fine
to
have
floor
time
in
this
working
group.
I
think
I.
F
A
That's
the
discussion
that
that
will
have
to
have
right,
I,
think
in
in
general,
where
we
have.
It
isn't
clear
to
me
that
we've
got
a
good
pattern
that
says:
ok,
this
is
the
you
know
the
level
of
benefit
that
one
has
to
have
demonstrated
to
adopt
something
different.
You
know
it's
actually
at
the
moment.
We
don't
really
have
a
huge
amount
of
competing
solutions
that
we're
looking
to
adopt
right
and
maybe
where
we
did
like
the
nsh
draft
and
the
the
service
programming
draft
we've
you
know
taking
them
on
their
own
merits.
A
A
A
A
H
H
We
have
gone
through
eight
revisions
and
individual
draft
and
we
have
gone
through
six
revisions,
our
working
group
document.
Throughout
all
of
these
revisions.
The
job
has
been
a
stable
and
they're
having
minor
changes,
but
significantly
since
the
last
idea,
we
got
a
lot
of
comments
from
all
the
Spring
community
I'm
going
to
review
them
today.
H
So
the
first
review
that
we
have
seen
is
Montrell
so
revision,
two
in
this
tribution.
What
we
have
done
is
we
have
done
an
integration
with
the
segment
routing
header.
We
had
already
anticipated
that
we
would
need
to
do
this.
This
editorial
update,
and
basically
this
consists
in
two
parts.
First,
in
all,
the
section
for
all
the
soda
codes
for
the
different
behaviors
happen
were
written
following
the
same
format
as
in
the
segment
routing
header
and
then
in
the
section
3.
H
We
have
replaced
many
of
the
existing
texts
in
network
programming
by
text
from
the
segment
routing
header,
which
was
already
covering
it
so
with
us
already
good.
Then
we
have
also
removed
three
sections
from
the
draft.
The
first
is
the
end
that
is
behavior.
This
was
a
behavior
that
was
at
least
quite
amateur
and
it
was
research
items.
H
H
Then
we
went
into
rebus
and
three
in
revision.
Three.
What
we
have
done
is
we
have
moved
the
transit
behaviors
that
relied
on
sorry
insertion
into
a
new
separate
graph.
So
this
graph
is
an
individual
drop,
so
draft
visa
spring
is
a
v6
net.
Pgm
insertion
and
the
these
transit
behaviors
with
insertion
are
already
deployed
and
are
working,
but
there's
an
ongoing
debate
with
six-month.
H
So
we
just
moved
in
into
a
separate
individual
draft
and
we
also
moved
as
well
the
by
Nasik
with
insertion
into
this
document,
then
in
remission
for
we
added
also
some
detail
updates.
So
mainly
we
did
some
clarifications
on
the
difference
in
between
the
SR
b6
it
function
and
their
behavior,
so
the
behavior
is
going
to
be
the
actual
pseudocode
that
you
are
going
to
execute
and
the
seed
function
is
the
the
bit
string.
That
is
actually
bound
to
a
particular
behavior.
H
Then,
following
up
from
discussions
that
we
have
in
Montrell,
we
have
also
updated
the
encapsulation
when
we
are
good
doing
either
in
it.
So
when
we
have
an
either
netting
absolution
before
we
were
using
the
snakes
header
value
at
v6,
no
next
either
59.
So
there
was
a
discussion
during
Montrell
whether
these
values
should
be
used
or
not.
We
had
a
discussion
at
the
mailer
with
with
six
men
on
a
screen,
and
the
outcome
was
that
we
should
request
a
new
value
for
either
on
it.
H
So
that's
what
we
did
and
also
in
the
Security
section
of
network
programming
on
section
7,
we
had
security
considerations
for
intradomain
deployments,
with
the
security
rules,
sequence
x,
2,
6
3.
By
the
time
that
we
publish
the
first
revision
of
the
graph.
These
were
not
covered
by
the
then
over
time.
This
was
being
a
cover
with
more
depth
in
the
segment
routing
header,
and
we
just
have
replaced
the
entire
security
section
with
intradomain
deployments
in
our
reference
for
the
Sigma
routing
header.
H
H
We
also
did
some
clarifications,
particularly
regarding
the
preamble
and
the
frame
check
sequence,
just
mentioning
that
these
are
going
to
be
a
strip
before
we
are
encapsulating
them.
Regarding
this,
Ethernet
is
also
important
for
the
working
group
to
note
that
we
have
requested
the
earlier
location-
and
this
is
I'm
going
with
it.
Sirs
and
80s.
H
So
I
beat
the
feedback
from
the
community
that
we
got
in
Montreal
and
after
so
we
got
a
lot
of
discussion
on
the
next
header
59,
as
I
have
just
explained.
We
we
actually
took
this
aside.
We
change
the
value
for
Ethernet
and
that's
it.
With
extension,
header
insertion.
We
have
decided
to
move
this
to
a
separate
draft
and
just
focus
on
sundries
and
network
programming
without
it
the
addressing
space
examples.
This
was
a
comment
that
was
raised
by
Lorentz
and
gender
in
the
last
ITF.
H
That
was
that
in
network
programming
we
had
some
examples
that
were
using
different
sizes
of
prefixes
and
it
could
be
misleading.
So
what
we
have
just
done
is
removed
these
examples
because
they
are
not
being
funded
for
the
standard,
and
then
we
had
the
definition
of
effective
next
header
in
the
draft.
We
have
actually
replaced
that
for
upper
layer
header,
as
in
the
segment
routing
header,
I,
beat
the
industry
stages
for
the
for
draft
and
running
code.
So
we
have
eight
open-source
implementations.
H
Three
of
them
are
a
packet
processing,
a
stack
so
kind
of
Linux
kernel
DVP.
We
have
some
open
source
applications
and
then,
if
we
move
into
the
hardware,
we
have
18
Hardware
implementations
and
these
implementations
are
from
a
different
vendors
and
it's
including
American
silicon.
These
implementations
have
participated
in
different
interrupts
events,
so
in
Sikkim,
2017,
NTC,
2018
and
2019,
and
we
are
already
working
on
the
NTC
2020,
where
we
will
have
more
vendors
coming
to
the
Interop
as
well
and
then.
H
H
H
So
run
in
RFC
8200
address
a
text
that
says
that,
regardless
of
the
order
of
extensional
headers
on
regardless
of
their
number
of
presences
or
the
number
of
occurrences
in
a
packet,
we
have
to
process
them.
So
in
SRV
six
network
programming,
we
are
not
suggesting
to
craft
a
packet
with
two
extension
with
two
segment:
outing
headers.
But
if
we
receive
a
packet
that
has
two
segments
routing
heather's,
we
must
process
it
as
per
RFC
8200.
So.
I
I
C
H
C
L
F
L
M
M
So
this
draft
was
first
presented
in
IETF
100,
but
there
are
three
yang
models
in
this
draft.
A
high-level
overview
is
the
base
model
which
defines
the
management
and
configuration
of
the
SR
v6
subsystem.
So
it
defines
things
like
locators
said
all
the
counters,
the
path
and
the
path
list,
among
various
other
data
structures,
and
basically
this
model
is
augmented
by
other
SR
v6
technology
models,
and
then
we
have
the
static
model
which
allows
user
to
program
locators
and
sets
in
the
forwarding
plane.
M
N
I,
just
have
one
comment
on
that.
You
didn't
comment:
AC
Linda,
my
Cisco
Systems.
We
did
that
in
the
base
for
a
lot
of
things,
we
thought
would
need
to
be
augmented
because,
unfortunately,
the
Yankee
Nam
tie
is
not
augmenta
below.
It
really
forces
you
to
use
identities,
and
this
will
help
in
the
future.
Two
more
add
boring
functions
with
augmentations.
M
M
O
O
One
defines
the
base
side
policy
types
to
define
some
of
the
common
types
and
basic
types
that
we
want
to
use
across
across
our
models,
as
well
as
beyond
our
model
and
the
main
module
is
called
I
TFS,
our
policy
module,
which
defines
a
model
for
the
self
policy
configuration
and
the
management
in
the
policy
types
module.
Basically,
we
have
defined.
O
Various
type
of
states
that
is
listed
in
our
policy
architecture
graph
is
also
incorporated
in
our
yang
model,
which
basically
burning
steady
state
policy,
state
path,
state
and
any
any
reasons
for
a
path,
candidate
path,
not
being
used
or
policy
being
down
and
whatnot.
So
if
we
really,
you
know,
take
a
thousand
feet
view
of
the
hierarchy
of
this
over
model.
Really
we
have
a
segment
on
traffic
engineering
as
a
top
container,
and
within
that
we
have
two
sub
trees.
One
is
like
attribute
related
tree
and
other
is
really
related
to
the
policies.
O
Attributes
are
really
the
common
attributes.
Are
costs
used
across
policies?
Examples
are
affinity,
maps,
segment
lists,
some
binding
state
related
rules,
and
the
policy
has
really
you
know
is
a
tree
that
to
keep
a
per
policy
configuration
and
management
model,
and
within
that
policy
there
are
some
policy
specific
stuff
and
then
the
candidate,
a
path
sub
tree
and
in
candidate
path
could
be
an
explicit
or
a
candidate
path
or
an
or
dynamic
type
of
explicit
path,
so
zooming
in
a
double-clicking
into
these
sub
trees.
So
the
attribute
tree
really
has
an
affinity
map.
O
A
segment
list
and
segment
lists
can
define
any
type
of
segment
from
the
base
policy
document,
and
then
we
have
explicit
binding
said
rule
that
whether
you
want
to
do
allocate
explicit
binding
set
from
srl
B.
You
want
you
to
enforce
it,
you
want
it
to
fall
back
on
dynamic
and
whatnot.
So
everything
that
is
an
SR
policy
document
is
part
of
this
young
model
in
the
attribute
section.
If
you
go
to
the
policy
sub
sub
tree
of
this,
this
module,
then
the
within
policy
we
have
you
know
a
policy
key
which
is
color
endpoint.
O
As
per
our
architecture.
You
can
also
have
a
name
based
policy
tree
if
you
want
there's
a
administrate
priority
of
the
policy
and
then
the
candidate
path
zooming
into
candidate
path.
Canada
paths
keys
as
as
as
far
as
our
policy
architecture
document,
which
is
protocol,
origin,
originator,
discriminator
and
the
prayer
and
the
discriminator,
and
you
can
also
have
a
preference
and
name
for
the
for
a
candidate
path.
O
It's
not
mandatory,
but
but
if
you
you
choose
to
and
within
the
candidate
path,
you
have
an
explicit
candidate
path,
type
or
dynamic,
Canada
path,
type
within
explicit
candidate
path
type.
You
can
specify
one
or
more
segments
list
which
is
defined
in
the
attribute
section
of
the
of
the
of
the
model
and
then
for
the
dynamic
I
think
this
is
the
major
mentioned
we
made
in
the
last
revision
of
the
draft.
O
We
did
not
have
the
dynamic
attributes
in
the
our
first
version
of
the
policy
draft,
a
young
young
draft,
so
we
added
some
dynamic
attributes
and
constraint
into
a
draft
to
cater
for
dynamic
type
of
a
candidate
path
and
also
along
with
that,
we
goes
with
the
management
of
these
things.
An
operational
State,
operational
State
is
is
basically
pertaining
to
the
policy
state
as
well
as
well
as
candidate
path,
state
and
the
reason
for
for
something
being
odd,
not
being
available
or
being
down
I'll.
Let
you
look
at
the
door
later
on.
O
We
also
added
some
modification
of
other
some
important,
even
related
to
the
Assad
policy
management,
which
are
really
related
to
the
status
of
the
policy.
The
candidate
path
active
status
as
well
as
change
of
candidate
path
or
one
being
selected
over
the
other
and
whatnot,
as
well
as,
if
there's
a
collision
about
the
explicit
binding
state
events,
that's
also
captured
in
our
model.
O
We
have
few
pending
items
which
are
really
related
to
traffic
string
and
odeon
templates.
Having
said
that,
there's
also
a
companion
document
which
is
BGP
SRT
yang,
which
we
also
have
submitted
an
idea,
as
that
document
already
captures
this
traffic
string,
as
well
as
odn
templates,
so
I
think
waters
will
be
working
with
authors
of
the
other
draft
to
see
how
we
can
align
both
of
them
together.
The
other
draft
align
augments
our
policy
draft
and
we
might
have
some
RPC
action
in
feature
as
well.
O
So
really
as
a
next
step,
this
document
has
been
around
for
multiple
ideas.
Now,
first
time
you
have
a
chance
to
present
this
mainly
because
of
tight
spring
agenda.
I
think
our
document
is
a
good
good
shape.
It
is
totally
aligned
with
over
a
third
policy
main
document
in
segments
working,
a
spring
working
group,
and
we
are
asking
for
a
working,
a
working
group,
adoption
of
our
SR
policy
and
graft
in
this
ITF
and
also
looking
forward
to
any
feedback
and
working
group.
You
know
input
on
over
document
to
make
it
enhance
it
further.
K
O
Think
the
affinity
map
is
yes
for
some
of
this
dynamic
constraint
that
you
want
to
add
to
the
policy.
Having
said
that,
we
have
received
this
input
as
well,
that
some
of
this
could
be
leveraged
from
existing
tt
modeling,
I
guess
and
we
are.
We
are
looking
forward
to
see
that
how
we
can
align
with
the
color.
K
J
J
J
Q
Q
Okay
good
morning,
I'm
attention
from
China
Mobile,
and
here
we
give
we
have
to
draft
wise
for
the
unifying,
see
the
use
key
style,
as
the
other
is
for
the
solution,
and
we
combine
the
both
presentation
together
in
this
society
and
further
unified
City
I.
Think
we
just
wanted
to
give
some
brief
ideas
here.
Q
So
from
the
operative
point
of
view,
I
think
is,
as
other
six
give
a
record
the
solution,
and
we
should
appreciate
it
as
a
basic
working
group
here
and
but
when
we
consider
to
deploy
as
five
six,
we
met
some
challenge,
so
here
I
just
want
to
give
some
our
understanding
on
that.
The
first
point
is
that
if
we
want
to
develop
the
deployer
new
as
a
v6
Network,
we,
the
first
thing
we
should
consider-
is
that
how
we
can
open
the
TE
traffic
solution?
Q
Q
So
here
I,
just
given
more
than
eight
segments
in
SH,
should
be
support.
This
is
I
I
collected
a
lot
of
different
requirements
from
several
operators.
The
similar
requirement
under
the
asking
is
that
currently
we
have
already
deployed
and
ipv6
for
several
years.
So
if
we
need
reapplying
the
ipv6
address,
that
would
be
bad
and
the
other
thing
that
we
have
a
too
big
existing
network.
We
hope,
based
on
existing
hardware.
We
can
support
the
basic
as
a
v6
solution,
so
we
want
as
a
v6
it's
a
friendly
for
the
hardware.
Q
Is
that
friendly
for
the
existing
network?
So
here
the
problem
we
want
to
give
is
that
the
over
height
of
the
as
a
Mystics,
when
we
consider
10
seats
in
the
as
I
H,
that's
a
huge
override,
only
60%
payload
that
can
be
carried
by
that.
That
is
a
terrible
and
a
compared
to
the
as
I
am
Paris
even
10
seats.
We
still
can't
get
more
than
90%
over
a
payload,
so
as
a
v6.
Q
If
we
want
to
support
80
in
the
bigger
network
that
is
really
hard
and
what
we
rise
to
unify
the
city,
we
want
to
solve
the
problem
and
we
wanted
to
deploy
that
in
our
existing
night
work
in
a
pistol
on
the
discussion
this
morning.
I
think
we
respect
the
current
as
a
v6
work.
I
think
that
is
great
work.
So
the
principle
for
us
to
develop
the
unified
Seder,
the
first
one
is.
Q
We
keep
the
compliant
with
the
standard
as
I
age,
that'sthat's,
great
idea,
and
the
other
thing
is
that
we
want
to
keep
complaint
with
as
a
v6
programming
or
as
a
v6
operation.
That's
all!
So
that's
our
principle
and
here
I
give
a
picture
and
we
change
the
receiver
side.
How
would
our
ingenue
as
a
v6
handling
and
the
blue
box
is
original
and
for
currently
I?
Think
in
ATF
group
we
have
several
alternative.
We
to
improve
the
as
a
basics.
Processing
I
give
a.
Q
Green
box,
so
each
of
them
needs
some
transforming,
summon
needs
50,
the
state
of
shifting
some
needed
citizen
stitching
and
what
we
provided.
We
want
to
have
a
mapping
table
to
solve
the
problem
because
you
know
for
the
switching
or
wanting
cheap,
it's
very
hard
to
support
a
complicated
logic
to
precise
the
SRH,
but
it's
very
easy
to
support
some
looking
up
table
to
support
it
because
it
have
resources,
they're,
so
pissed
on
our
understand.
Even
Clinton
can
support
it.
Q
We
will
give
some
Pusey
later
and
the
unify
the
see
the
format
is
of
a
very
simple.
We
will
support
something
like
NPR's
labor
to
support
the
state
and
the
basically
format
of
labor
is
that
we
will
use
reuse.
The
existence
eat
assignment
for
as
I
am
peers.
It
makes
it
easy
to
upgrade
from
assign
peers
to
as
a
v6.
Q
P
I
can't
allow
liquor,
Cisco
Systems
a
couple
of
comments.
One
is
I
think
the
proposal
is
to
put
a
lot
of
different
different
mappings
into
the
SRH,
which
was
meant
for
SRB
succeed.
What
I'd
like
to
remind
is
that
we
have,
in
the
spring
and
mpls
working
groups,
develop
solutions
for
ipv6
using
mappings
or
labels.
So
that's
really
something
that
the
working
group
has
already
solved
and
addressed.
P
I
Yes,
so
yes,
that's
true!
What
we
wanted
to
achieve
here
or
preserve
is
that
what
with
you
as
a
important
benefit
of
SRH,
that
preserves
the
path
information
from
the
source
to
the
destination
and
asaram
pls
in
IP,
as
Saran
pls,
does
not
that
do
that.
So
that's
what
we
think
that
the
big
differentiator
of
unified
state
proposal
to
use
SSH
and
thus
preserve
the
path
information
of
SR
MPLS
path,
which
is
a
benefit
okay.
I
P
So
one
is
SRH
was,
is
designed
to
carry
SRV
succeed.
I
would
think
just
using
the
header
for
carrying
something
different,
you
know
is
not
really
the
same
SRH
and
the
other
thing
is
yeah.
We
have.
There
happened
the
interworking
solutions,
so
we
should
look
at
it.
We
can
discuss
more
offline,
but
is
that
yeah.
I
P
B
Okay,
QT
compeller
a
couple
of
things:
one
is
in
the
draft.
You
say
that
this
is
a
way
to
upgrade
from
SR
v6
to
SR
MPLS.
It
seems
to
me
that
you're,
more
likely
gonna
go
in
the
opposite
direction,
because
there's
more
SR,
MPLS
deployments,
then
there
s
our
v6,
so
I
think
it's
useful
to
talk
about
that
particular
option
as
well,
or
maybe
even
talk
about
that.
First.
B
The
second
thing
is
you're,
saying
unified,
said
and
you're
talking
about
SR,
v6,
SRH
and
you're.
Talking
about
SR
MPLS.
Are
you
planning
in
the
future
to
talk
about?
You
know,
having
said
a
couple
of
times
that
the
SR
v6
is
very
heavy
and
and
kind
of
big
SIDS.
Are
you
looking
at
as
our
m6
as
another
option
within,
because
you
only
have
two
bits
for
your
types,
so
you
are
kind
of
constrained
on
what
types
of
I
mean
this
unification,
the
space
of
unification
is
limited
to
four
right
now.
Q
So
I
think
the
second
question
is
about
our
flag:
I.
Think
it
the
flag
here
is
the
indicator,
what
kind
of
say
that
we
are
using
in
the
list
and
we
we
just
give
some
proposal
if
we
can
use
that
that
is
a
result
beat
to
represent
at
that,
but
I,
don't
think
it.
It's
a
broken.
The
as
our
basics
rules
there
Greg.
I
Network
with
the
Sorrento
s
and
as
a
service,
six
or
ipv6
networks
come
up
so
to
extend
their
programming
of
their
network
path
using
the
same
mechanics.
It's
operationally
changes
in
terms
of
what
scenario
what
can
be
used
using
this
two-bit
flag,
as
you
notice
I.
We
think
that
for
backward
compatibility
we
need
to
be
compatible
with
the
ipv6.
It's
ok,
so
0
0
is
given.
Then
we
propose
to
use
one
of
them
to
be
too
well
to
use
a
certain
terrorist
case.
Two
others
are
open
for
discussion.
I
C
Darren
Francisco
just
want
to
bring
up
a
couple
points.
We
have
you
know
RFC
402,
which
is
the
s
architecture
document.
We
have
a
s
our
MPLS,
our
v6
interworking
draft.
We've
got
a
couple
of
compression
mechanisms
that
work
without
any
sort
of
mapping
table.
We
have
what
I
think
was
18
implementations
from
8
different
vendors
of
SR
v6,
so
I
guess
obviously
those
merchants.
C
Silicon
vendors
are
implementing
SR
v6
without
a
mapping
table
I'm
gonna,
reiterate
something
that
I
said
at
the
beginning
and
I
think
that's
applicable
to
this
and
the
other
work
that's
going
on
with
SRM
6.
Is
that
there's
no
description
of
what
this
work
brings
to
the
table
for
this
working
group
or
for
the
community
large
over?
C
Q
C
Q
O
Comer's
or
Cisco
Systems
first
I
found
this
statement
that
mapping
solution
is
easier
to
implement
in
chip,
even
in
existing
as
a
chip.
I
found
it
interesting,
but
my
men
and
I'm
not
sure
this
is
quite
accurate
because
you're
an
additional
map,
a
mapping
table
you're
talking
about
in
hardware,
but
my
main
questions
about
the
performance
impact.
So
once
you
have
asset
mapping
table
right,
this
is
additional
mapping
table
and
additional
lookup
in
the
hardware
most
likely.
So
you
haven't
touched
upon
that
angle.
So
can
you
comment
from
performance
impact
if
any
for
your
solution.
I
Gregg
mercy,
City
I,
believe
that
if
you
compare
this
solution
with
the
reference
earlier
MPLS
in
IP,
then
there
is
no
additional
impact.
So
basically
it
will
be
the
same
processing
in
the
same
number
of
mappings
that
you
need
to
maintain
yes,
so
again
compared
to
a
certain
pls,
an
IP
and
it
works
in
wire
speed.
So
again,
no
problem.
K
R
One
okay,
I
think
these
two
user
regarding
this
is
the
compression
of
the
SME
6s
are
active
header,
so
I
think
it
is
a
two
point
he's
a
very
important
I
think
that
the
first
one
user
requirement
so
I
think
here
you,
the
proto
the
case
I
know
that's
the
China
Mobile
you,
the
important
operators,
so
I
think
I
use
a
better
that
you
can
have
some
statistical
information.
That's
just
this
information!
You
understand
this.
R
How
much
for
the
size
of
the
use
of
the
packet
under
the
distribution
and
also
these
are
the
according
to
the
deployment,
how
many
segments
use
necessary,
I
seen
the
DCU.
The
may
be
used
more
useful
for
us
to
understand
that
this
is
the
requirement.
So
this
is
the
first
one.
The
second
one
I
think
that
is
the
the
cost
of
the
new
solution
for
this
one.
R
So
I
think
that's
the
you
better,
because
now
the
probe
holder,
you
Lucas
and
also
is
better
according
to
this,
the
forwarding
plea
and
also
to
identify
some
other
requirements
such
as
the
many
the
plane
or
the
controlling.
So
that's.
According
to
this,
we
can
understand
that
is
the
advantage
and
also
the
possible
cost.
So
that's
we
can
yeah.
Thank.
Q
Q
35,000
note
to
support
the
full
city:
fevzi
backhaul,
that's
huge
right!
So
in
this
huge
network
we
have
to
manage
each
pass
between
the
position
at
the
core
network
of
5g.
The
number
from
is
the
4G
network,
so
for
5g,
that's
similar,
so
35
thousand
nodes
in
one
network
is
huge.
The
management
that
can
chew
is
challenged.
So
that's
we
have
a
very
detailed
calculation
to
calculate
how
many
seats
should
be
included
in
the
height,
and
our
number
currently
is
a
12.
Q
Now
we
are
developed
deploying
the
MPR
size
are
for
this
network
and
we
have
deployed
a
more
than
five
thousand
nodes
tuna
and
based
on
this
network,
we
have
a
to
support
more
than
10
seats.
Oils
is
very
hard
for
us
to
operate
that
so.
Thus
its
number
is
related
to
the
network
scalability
for
the
biggest
city.
We
have
a
to
help
more
than
10
leva
seats,
that's
challenger
for
the
SR
Mystics
now.
Q
So
that
means
it's
very
hard
for
us
to
use
the
Asami
6
in
this
network
in
this
application
error,
because
this
table
the
60
percent
utilization
of
the
bandwidth,
it's
terrible.
So
we
have
to
improve
the
solution,
or
else
we
cannot
get
the
largest
scalability
deployment
on
that.
Thank
you
and
then
the
second
one.
Yes
I.
Currently
we
just
have
app
you
see
on
the
data
plan
and
then
maybe
future
we
will
have
more
detailed
analysis
on
the
control
plan
and
a
manual
client.
Thank
you.
Okay,.
I
Gt,
yes,
thank
you
for
bringing
it
and
that,
in
addition,
some
other
activity
is
for
future
work.
So
we'll
do
that
and
again
we
welcome
comments
who
are
welcome
collaboration.
So
if
somebody
wants
to
work
together
and
in
this
aspect,
comparing
with
the
micro
seeds
or
with
other
suggestions,
enhance
or
do
this
yeah
we're
welcome.
But
yes,
we
were
planning
to
do
more
detailed
comparison
with
the
micro
seeds.
Q
T
Q
F
J
You
so
going
back
to
your
question.
It's
part
of
the
subject
beyond
as
a
v6,
so
stable.
We
first
need
to
really
agree
on
what
the
goal
is
or
are
we
can't
pursue
at
too
many
requirements
compared
to
the
original
scope
of
Springer
in
we
we
had
recommends
at
the
beginning.
We
caught
multiply
the
number
of
requirements.
We
heard
that
there
are
some
use
case
with
lot
of
seeds
and
for
those
whose
case
we
need
to
reduce
the
size
of
the
reader.
J
But
in
addition
to
that,
we
didn't
really
understand
the
real
out
calls,
and
then
we
have
to
discuss
the
benefits
on
cost
of
each
solutions,
not
specific
to
use
it's
all
the
solutions,
because
we
don't
know
we
don't.
We
should
not
assume
that
we
are
going
to
go
to
for
solutions
to
six
manner,
I
mean
for
solution
in
addition
to
a
36,
so
we
really
need
to
converge
with
in
spring
first
well
it
to
everyone
to
discuss
the
cost
and
benefit
analysis
of
each
solution
free
to
converge
on
something.
I
Just
final
question
from
as
offers
that
what
we
asked
for
their
chairs
to
the
clarify
where
this
work
can
continue
and
if
it's
to
continue
in
spring
group,
would
we
need
to
resubmit
the
draft,
the
draft
with
points
to
the
spring
group?
We
just
need
your
qualification
of
wine
on
owner
list.
Thank
you.
J
O
J
O
C
O
O
O
However,
there
are
like
a
sum
of
these
traps,
which
we
believe
are
like
quite
mature,
specifically
because
there
has
been
implementations
both
on
software
and
as
well
as
like
on
a6,
and
there
has
been
interoperable
implementations,
so
I
would
just
like
a
go
through
those
which
we
believe
are
mature
now.
First,
one
is
the
service
6
plus,
which
actually
gives
an
overview,
and
then
we
have
a
routing
header
definition
that
we
believe
is
pretty
mature
because,
as
I
said,
like
a
that
has
been
implementation,
both
on
software
and
a
second,
there
has
been
interoperable
implementation.
O
The
other
one
VPN
desktop
it's
a
very
straight
forward
draft
and
we
believe
there's
an
implementation
and
we'll
use
that
one
is
also
mature.
So
now
otherwise,
from
the
last
IETF,
we
have
a
new
draft
which
is
CRH
helper
op.
So
the
orders
are
over
here
itself.
So
if
anybody
has
like
gone
to
the
draft
and
if
they
have
any
suggestions
or
comments,
they
can
actually
directly
reach
out
to
them.
So
in
essence,
it
actually
defines
a
new
ipv6
destination
option
that
actually
carries
the
mapping
from
the
CRX
it
to
the
ipv6
address.
O
They
do
it
efficiently.
So
I
didn't
go
into
the
details,
because
the
draft
is
like
a
pretty
much
clear
on
that.
So
any
doubts
you
can
actually
ask
so
with
respect
to
the
development
and
deployment
we
have
a
code
which
is
like
a
linux-based
and
we
have
an
acid-based
implementation
also,
which
is
now
which
is
on
MX
and
there's
a
DP
DK
implementation
from
liquid
telecom
regarding
the
deployment
Andrew
would
be
talking
after
me,
so
I
didn't
get
down
to
that
and
with
MX
based
POC.
O
There
are
like
other
deployments,
which
are,
which
probably
would
be
like
a
coming
on
coming
quarter
and
with
respect
to
the
drafts
which
needs
to
be
returned
right.
There
there's
a
noise
PF
extension
similar
to
ISAs,
which
needs
to
be
returned
and
there
is
a
young
model
which
needs
to
be
defined
and
from
this
presentation
the
ask
is
actually
to
for
the
community
to
actually
review
the
mature
drafts
because
those
has
been
implemented
and
you
have
like
a
implementation
on
both
a
sick
as
well
as
like
on
software.
O
C
Jaron
from
Cisco,
so,
like
I,
said
on
on
the
last
draft
at
the
beginning,
there's
there's
there's
we
don't
see
any
justification
for
this
SRM
six
work
beyond
with
the
working
groups
already
chartered
to
deploy
our
Charter
to
produce
and
is
producing
and
multiple
vendors
and
operators
are
currently
deployed.
So
there's
no
there's
no
comparison
document.
There's
no
justification
for
why
this
work
is
a
value
to
the
community
and
I.
O
D
Darin
I'd
like
to
add
a
couple
of
things
to
that.
Firstly,
I
go
back
to
Montreal,
where
we
were
asked
by
the
operators
to
put
down
the
justifications
of
something
needed
in
addition
to
s
or
v6.
This
was
done.
There
were
multiple
emails.
That
I
can
point
you
to
on
the
list
from
ourselves,
I
believe
from
entity
from
others
about
the
justification
needed
for
something
additional.
D
Secondly,
I
point
out
right
that
I
myself,
as
an
operator
operating
a
large
network,
was
asked
a
question
about
the
depth
and
deployment
and
whether
or
not
the
current
technologies
could
be
utilized
and
I
laid
out.
The
scenario
and
I
put
it
back
and
I
was
told,
there'd
be
a
response.
That
exchange
was
between
you
and
me
so
to
stand
here
and
say
that
there
is
no
justification
considering
the
work
that
has
gone
on
on
the
list
where
it
was
asked
for,
it
was
replied
to
is.
C
So
the
question
is,
where
suggested
where's
the
where's,
the
detailed
description
of
how
this
work,
how
the
solution
this
is
trying
to
solve
is
not
already
solved
by
what
exists.
There's
methods
of
reducing
reducing
the
size
of
a
a
header,
there's
SR
v6
is
is
already
has
an
architecture.
Doc
unis
is
has
the
control
plane
to
find
its
it's
deployed.
So
it's
it's
back
on
the
authors
of
this
work
to
describe
why
the
current
work
of
this
working
group
is
not
applicable.
C
D
So
first
thing
I
think
that
it
needs
to
be
made
very
clear
that
the
authors
of
SRM
six
have
stated
multiple
times
on
the
list
that
we
do
not
want
to
impede
the
work
of
what
is
currently
going
on.
We
believe
that
there
needs
to
be
a
choice
and
let
the
market
decide,
and
we
believe
that
both
should
progress.
I
also
point
out
that
if
we
look
and
when
we
talk
about
finalizing
one
before
the
other,
there
is
one
architecture
document
before
this
working
group.
D
At
the
moment
it
is
SRM
6
s,
rh
is
sitting
in
six-man.
It
is
not
in
this
working
group,
network
programming
and
CRH
and
SRM
sex
perform
very,
very
different
functions,
very
different
functions.
If
you
get
to
the
Micra
said
draft
I
point
out
that
the
CRH
draft
actually
predates
that,
and
so
the
same
onus
that
we
have
to
produce
the
justification
for
what
homes
in
CRH
sits
on
the
authors
of
the
Micra
so
draft
and
is
equally
absent.
D
However,
considering
that
the
authors
of
the
microsil
draft
wrote
the
micro
CID
draft,
they
themselves
have
acknowledged
considering
they
are
the
same
authors
on
the
original
sov
six
draft,
that
something
has
to
be
done,
that
there
is
a
problem.
The
document
itself
stands
as
an
acknowledgment
to
the
problem
of
the
overhead,
and
so
the
same
owner
supplies
there.
So
I'm
a
little
confused
here
as
to
what
the
stance
is
and
if
you
can,
if
you
can
explain
it
to
me
better,
considering
everything
that
I've
just
said.
G
D
C
D
C
You
have
a
solution
that
has
a
RFC
8080
402,
which
is
the
SR
architecture
document.
You
have
a
lot
of
work,
that's
been
done
in
the
working
group.
You
have
a
lot
of
work,
that's
been
done
in
the
industry,
you
have
a
lot
of
deployment,
it's
going
the
way
it's
going.
What
I'm
simply
stating
is
that
there
is
a
lot
of
background
work
to
build
that
documentation
set,
and
this
working
group
and
I
don't
see
the
same
level
of
background
for
this
work
and.
D
D
And
and
I
would
say
to
you
that
there
is
a
lot
of
work
that
has
gone
ahead.
I
will
point
out
that
when
the
questions
have
come
from
the
working
group,
we
have
attempted
to
address
every
question
that
has
come
up.
We
there
were
requests
in
Montreal
put
for
justifications
to
the
list
by
the
chairs.
The
request
went
out.
It
was
answered
on
in
some
detail
and
I'm
quite
happy
to
point
out
those
emails.
D
My
point
here
is
that
I
really
do
believe
that
there
is
a
lot
of
work
that
has
gone
on
into
making
this.
What
it
is
today-
and
the
authors
have
said
very
clearly
that
if
this
working
group
feels
that
they
are
technical
problems
with
it,
technical
changes
bring
them
to
us
and
where
they
have
been
brought
to
us.
We
have
attempted
to
engage
to
address,
but
at
this
point
I'm
I'm
not
quite
sure
what
it
is
that
you
want
from
us
and
I'm
quite
happy
to
have
an
offline
email
exchange
to
understand
that
better.
P
Yeah
yeah
can
I,
so
this
gate,
ontological
Cisco,
so
this
proposal
is,
is
mapped.
Mapping,
SRM,
six
mapping
right.
We
have
our
two
decade,
plus
old
technology
for
mapping
just
called
MPLS.
I
would
like
to
point
out
that
when
we
are
talking
about
ipv6,
we
have
already
in
the
working
group
defined
as
our
MPLS
for
ipv6.
We
also
define
it's
in
the
RFC
queue:
how
to
do
s
our
MPLS
over
IP,
only
network,
that
is
s
our
MPLS
over
IP.
All
of
these
are
there
right.
When
this
proposal
was
brought
out.
P
D
I
think
that,
as
as
I've
stated
on
the
mailing
list
right,
there
is
a
demand
out
there
in
the
market
to
move
away
from
MPLS
labels
at
the
top
of
the
packet,
and
we've
seen
it.
I
was
told
very
bluntly
by
a
particular
vendor
that
there
would
be
no
further
control
plane
development
done
in
v6
as
regards
MPLS
right
now.
Our
take
on
this
is
is
that
in
the
current
SR
v6
as
it
stands
and
I
have,
as
I've
said,
no
wish.
D
None
of
our
authors
wish
to
block
the
deployment
of
SR
v6
or
the
development
of
it.
We
simply
argue
that
there
is
a
need
for
the
ability
for
a
far
deeper
sin
stack
and
they're
all
requirements
for
it.
If
you
look
at
the
prepared
at
the
previous
presentation,
they
were
talking
about
a
said,
a
tensed
depth.
That
is
a
requirement.
I
myself
have
a
need
for
tensor
debt.
If
you
look
at
the
overhead
imposed
by
s
or
s
or
v6
in
the
absence
of
the
white
person,
trust
so.
P
I
suggest,
if
I
could
kind
of
paraphrase
you
sorry
is
what
you
are
saying
is
that
with
SR
MPLS,
this
solution
for
ipv6
only
network
is
solve
our
address
by
whatever
work
has
come
out
of
spring
working
group
and
MPLS
right.
But
what
you
are
what
we
are
looking
for.
So
that's
the
case
right
did
I
understand
it
correctly,
so
which
is
our
MPLS.
P
Just
to
say
that
was
what
I
was
asking
about,
so
this
is
addressed
or
solved
with
SR
MPLS
right
for
ipv6
networks,
with
ipv6
control
planes,
with
whatever
work
we
have
done.
I
think
I
mean
I,
find
it
a
bit
odd
because
we
are
introducing
a
mapping.
Technology
and
mapping
is
very
similar
to
MPLS
and
we
have
done
all
of
that
work.
So
Jukka
is
not
introduced
as
far.
D
D
In
protocols,
operators
right
many
operators
want
a
choice.
They
want
to
be
able
to
say
got
this
option,
got
this
option
right
and
sure,
I
and
and
what
I
am
saying
and
again
I
repeat
right:
there
is
no
desire
to
block
the
continued
development
in
S
or
v6.
We
merely
believe
that
there
is
an
alternative.
There
was
a
stated
requirement
for
what
the
alternative
offers
on
the
list
as
requested
often
Montreal,
and
as
such,
we
believe
that
both
should
be
able
to
proceed
so
can
we
cut.
A
F
There
are
those
questions:
what
are
the
differences
between
us
or
entities
at
the
end
of
the
or?
What's
the
motivation
for
us
our
index
at
the
end
of
the
SRM
six
documents?
There
is
a
section
that
calls
out
the
major
differences,
see
our
excise
decoupling
of
network
programming
with
traffic
engineering.
There
were
key
words:
we
can
beef
up
that
section
a
little
bit
in
the
next
revision
and
you
know
call
them
out.
F
As
you
know,
the
real
motivation
for
SRM
specs
Oh,
one
of
the
major
motivations
that
you'll
see
in
this
next
version,
is
that
as
SRM
sex
does
many
things.
Traffic
engineering,
fast,
reroute,
VPNs,
perfect,
no
service
instructions
and
it
decouples
them
so
that
if
a
network
operator
wants
to
use
one,
the
owner
or
some
combination,
that's
fine.
Also
it
does
a
good
job
on
all
of
them.
F
It
can
do
traffic
engineering
without
requiring
the
network
operator
anomalies
network
in
any
particular
way
it
can
do
traffic
engineering
using
adjacency
since
as
deep
as
it
needs
to
go
so
in
any
of
it.
Your
your
comment
is
well-taken
you'll
see
an
update
in
the
next
revision
of
that
section.
That
pulls
out
differences
will
become
more
on
motivation.
F
C
F
C
F
L
L
L
Plane,
new
data
plane
and
deviating
from
architecture.
This
is
why
you
need
to
work
on
this,
because
there
is
there's
a
whole
list
of
documents
that
Andrew
just
showed
on
the
list.
It's
all
control
in
document
in
tied
in
you
to
control,
claim
entirely
new
data
plane
and
in
very
different
architecture.
This
is
why
you
need
to
justify
why
the
60s.
E
Jim
from
future
well,
I
was
actually
going
to
reiterate
that
point.
That
might
my
concern
here
is
that
we're
gonna
we're
being
asked
to
develop
two
completely
incompatible
solutions
in
a
working
group.
That's
not
supported
by
the
current
charter,
and
if
you
look
at
that,
just
the
second
paragraph
of
the
Charter
is
specifically
says
that
we
should
avoid
working
on
incompatible
data
playing
solutions
for
existing
deployments
or
words
to
that
effect.
And
what
we're
being
asked
to
do
here
is
work
on
another
data
plane
that
is
completely
incompatible
with
SR
v6
and
that's.
D
D
Plane,
okay
I
need
to
make
a
point
here.
If
we
talk
about
data
plane,
compatibility
I,
published
on
the
list,
a
test
that
we
did
with
the
compressed
routing
header,
where
I
routed
on
and
steered
compressed
routing
header
over
my
network
out
across
the
general
internet
across
two
continents
into
another
network
and
took
up
the
steering
on
the
other
side
that
was
over
a
v6
data
plane.
The
traffic
steered
on
my
network,
its
steered
on
the
remote
network
across
multiple
ASNs,
with
no
knowledge
of
the
intermediate
area
networks.
D
E
K
E
Me
just
finish,
and
there
are
solution
documents
out
there
to
suggest
how
you
can
compress
the
SR
agents.
That's
a
discussion
we
need
to
have
all
I'm
saying
is
that
the
process
in
IETF
is
that
when
we
build
working
groups,
we
have
charters
they're
there
for
a
reason,
and
if
we're
just
gonna
ignore
what
the
Charter
says
without
going
through
the
process,
then
what
we
have
is
anarchy
and
I.
That's
my
concern.
I
do
not
want
to
be
working
on
two
completely
incompatible
solutions.
F
F
Whenever
we
stretch
that
and
scratch
that,
then
we
we
risk
stepping
out
of
charter,
you
know
I
think
we
do
need
to
stay
in
charter.
That
means
do
it
on
TV,
six
in
a
plane,
but
I
think
it's
a
bit
unfair
to
say:
SOR
v6
is
what
we
say
it
is
today,
even
though
we're
not
quite
finished
yet
well,
let's
let
it
evolve
and
also,
let's
be
very
meticulous
at
our
compliance
with
8200.
U
U
Actually,
that's
almost
the
only
thing,
I
want
to
say
I'll,
just
say
one
further
thing,
which
is
that
you
know
what
I
see
now
is
what
I
saw
a
bunch
of
years
ago,
which
is
that
there
are
some
people
who
are
trying
to
solve
what
they
say
is
a
a
demonstrated
problem
that
they
see
from
the
marketplace
there
they're
feeling
customer
pull
and
they
have
a
solution
they're
working
on.
They
would
like
to
work
on
it
in
the
light
of
day.
U
Toward
that
end,
they've
put
a
lot
of
work
into
publishing
a
set
of
documents
and
soliciting
input
on
them.
The
work
is
I
presume
and
I'm.
Actually,
I
should
say
that,
although
my
my
badge
is
Juniper
Networks
I
do
not
work
on
this
project,
but
you
know
work
isn't
going
to
go
away
because
the
IETF
says
la
la
la
I
can't
hear
you
that's
it.
R
Being
from
Hawaii,
I
have
two
comments:
the
first
one
is
the
requirements,
so
the
first
I
I
think
we
must
a
distinguish
that
would
have
the
requirement.
The
first
requirement
I
used
to
reduce
the
size
of
the
SRB
succeed.
Another
requirement
is
a
totally
new
SR,
the
ipv6,
the
based
the
SR
solution,
so
I
I'm
from
my
pond.
We
cannot
mix
the
two
requirement
together.
R
You
I
I
think
I
use
a
lot,
a
reasonable
way
to
say
that
we
want
to
reduce
to
the
side,
but
these
are
our
requirement
but
I
wanted,
but
that,
based
on
this
requirement,
I
make
a
totally
new
ipv6
to
face
the
solution.
As
our
solution
I
think
this
is
not
a
reasonable
way
so
I
also,
you
can
say
that
they
are
already
the
three
possible
solution
it
can
be
compatible
with
the
SRH.
It
can
also
reduce
to
the
side
of
the
SRB
succeed.
So
I
think
this
is
the
first
point.
R
The
second
point
I
think
this
is
a
process
usual
I
think
this
is
also
mentioned
that
that's
in
the
80s
mill
less
usually
focus
on
this,
the
SRS
standardization.
These
are
first
point.
Okay,
the
second
one
I
think
if
we,
you
said
that
is,
we
have
the
requirement.
Oh
may
I
said
that
you
also
comply
with
the
process
you've
had
this
is
the
this.
Is
the
proper
there's,
a
problem
statement
and
the
requirement,
so
this
one?
That's
a
user
Charter.
R
H
H
A
DA
I'm
not
discussing
about
this
Harvey
six
I'm
trying
to
discuss
about
your
proposal
and
if
I
wrote
the
introduction
of
draft
Bonica.
Sorry,
six
plus
you
are
defining
something
that
is
called
segment:
node
ingress
and
segment
node
egress.
Then
you
are
saying
that
the
segment
must
have
a
state
both
on
the
ingress
and
egress
and
to
me
that
looks
more
like
a
tunnel
than
rather
than
RFC,
84
I.
A
Think
in
reality,
if
we
rename
this
something
that
doesn't
say
segment
routing,
it
doesn't
change
the
problem
space
that
we
have
the
problem
space
is.
There
are
multiple
solutions
for
a
smaller
size
it
if
it's
segment,
routing
or
not.
The
potential
problem
gets
even
worse,
because
this
moves
to
our
ttg
and
things
just
happen
outside
of
any
kind
of
coordinated
view.
So
I
I
appreciate
the
point,
but
I
kind
of
feel
like
it's
not
necessarily
moving
it.
V
We
also
noticed
that
shouters
seed
has
opposite
advantages,
for
example,
handle
smaller
MTU
and
actually
because
in
some
cases
we
run
contributing
directly
control
the
seed.
Actually,
in
that
case,
we
do
not
really
need
128.
So
actually
we
both.
We
support
both
proposals
in
the
SRV
6,
because
it's
quite
a
merger,
so
it's
good
and
we
are
using
and
we
should
open
our
eyes
to
see
the
new
possibility.
Squeegees.
These
are
FC
and
probably
we
can
try
to
get
it
compatible
in
the
future
for
the
features.
V
O
Come
on
come
on
Cisco
Systems.
In
your
earlier
slide,
you
shown
one
CRH
and
three
option:
tea,
always
and
also
proof
of
concept
with
ASIC
based
implementation.
My
question
is
I'm
interested
know
that
how
many
are
on
ASIC
based
implementation?
How
many
of
those
options
at
the
line
rate
you
can
process,
including
CRH
and
three
other
options
that
you
have
listed.
U
O
Talking
about
your
earlier
proof
of
concept
on
asset
based
implementation
and
your
list
of
options,
there
are
three
options:
the
latest
being
CH
helper
option,
and
you
have
three
option:
T,
alvie's
and
oneness
your
H
address.
All
these
options
will
be
/c
RH.
How
many
you
can
process
on
a
sequence,
imputation
online
rate,
okay,.
P
O
T
T
D
J
J
We
need
to
make
sure
we
really
understand
the
the
problem
that
we
need
to
serve
and
because
we
are
airing
different
things
from
different
persons,
including
from
different
orders
as
a
document,
and
then
we
will
work
on
a
solution.
We
should
not
assume
we
are
going
to
push
for
additional
draft
or
traditional
solution
for
six
mana.
So
to
make
it
short.
If
the
goal
is
to
make
a
shorter
adder,
we
need
to
ask
to
all
the
proposals.
J
A
And
just
to
make
a
point,
follow
pointers
if
we
do
a
call
for
adoption,
we're
only
going
to
get
the
same
comments
that
we've
had
in
the
room
and
the
additional
ones
on
that
phases.
So
I
think
we
should
really
the
focus
before
we
kick
off
for
an
adoption,
for
anything
should
be
just
start
to
address.
Some
of
the
concerns
raised
in
the
working
group.
T
Come
on
everyone,
I'm
Charlie
from
Hawaii.
My
topic
today
is
about
as
a
v6
power
segment,
so
in
history
who
have
proposed
to
draft
about
as
amperes
part
segment
and
it
has
been
adopted
by
the
spring
working
group.
As
you
see
that
the
reason
is
in
there
some
peers,
we
cannot
identify
the
package
came
from
which
pause,
because
there
are
no
label
or
only
few
label
left
when
the
packet
reached
the
egress
note,
so
so
in
either
as
amperes
part
segment
right
so
to
support
use
case
like
like,
like
p.m.
T
T
The
information
of
the
series
cannot
identify
the
past,
so
we
need
an
ID
to
identify
the
the
sf-86
password,
so
we
propose
as
a
v6
power
segment,
which
is
fixed
lens
and
identification,
which
is
a
128-bit
ID,
and
so
the
main
update
of
this
document
is,
we
add
some
tests
to
clarify
the
requirements
of
a
v6
post
segment
and
we
move
the
encapsulation
related
test
to
another
document
in
a
six-man
working
group
and
we
update
the
references
and
we
make
some
like
editorial
a
modification.
So
a
question
and
comments
our
very
own
right.
T
So
this
is
the
s
a
v6
part
segment
encapsulation
in
as
a
v6
and
I
won't
go
into
the
details
of
this
solution
because
we're
talking
about
the
architecture
document.
So
if
I
interested
in
this
document
welcome
to
discuss
with
me,
so
we
mainly
propose
to
format
up
as
a
v6
segment.
The
first
one
is
a
global
ID
format
which,
which
is
like
it
can
be
a
it
can
be
a
128-bit
group
ID
and
the
second
one.
It
follows
the
format
of
a
v6
segment
which
has
the
located
and
function
ID,
something
like
this.
T
So
this
is
a
former.
The
processing
of
the
as
a
v6
per
segment.
I
won't
go
into
the
details.
What
I
want
to
mention
is
the
as
a
v6
power
segment
can
be
distributed
by
bgp
or
PCP.
This
app
and
you
have
to
documents,
have
been
adopted
by
idea
working
group
and
piece
piece,
a
PC
working
group,
so
it
can
be
very
easy
to
export
as
a
v6
by
some
minor
changes
right
so
the
next
time.
Q
J
J
W
From
University
of
Tokyo
and
I'm,
also
a
member
all
the
interrupts
talk,
it's
shown
it.
So
this
draft
would
like
to
share
the
Reston's
run
from
the
scariest,
our
basic
self
changing
deployment
at
the
interrupt
culture,
so
the
only
interpretive
still
continues
the
shown
it,
which
is
the
one
of
the
largest
demonstration
network
at
the
interrupt
Tokyo
interrupts
exhibition.
W
So
this
is
the
overview,
but
I
will
skip
this
turret
this
right
because
not
so
interesting,
and
so
they
this
risk
in
case
the
there
s,
our
basics.
Our
device
is
contributed
to
the
show
net
for
this
experiment
from
Cisco
and
for
a
required
Creek
and
NTT
communications.
Vio
went
back
and
so
on.
So
pretty
the
draft
about
the
detail
of
the
product
and
they
are
the
sub.
The
product
is
our
basic
sub
chaining
as
the
Assad
physics
unaware
services.
That
means
that
they
are
deployed
under
the
end
am
proxy
or
attacking
proxy.
W
The
tagging
proxy
is
proposed
at
the
show
net
and
the
draft
is
also
published,
and
so
let
me
introduce
or
share
the
Reston's
around
from
this
experiment.
So
the
first
so
we
we
were
yeah.
We
were
worried
about
that.
Such
a
hot
meter
boxes
keep
passes
past
the
ipv6
packet
with
a
sorry
age
under
the
Ada
and
AM
proxies,
but
there
was
no
worried
and
all
devices
contributed
to
the
show
net.
This
year,
transparent,
transparent.
We
delivered
all
the
ipv6
packet
with
a
storage
under
the
end
a.m.
W
proxies
implementations
from
some
vendors
repeaters,
and
so
next,
so
we
directory,
we
tried
to
deployed
a
skeptic
Porter
under
the
a
proxy
for
Wi-Fi
users,
but
it
couldn't
be
done
because,
as
mentioned
in
the
draft,
is
our
service
permit
programming
the
services
they
originate
pocket
from
the
service?
Each
F
cannot
be
deployed
on
that
and
the
in
proxy,
because
the
demonstrating
requires
a
sorry.
They
must
create
a
sorry
to
is
the
pocket,
but
such
packets
from
the
subsist
don't
have
less
much
credit
SRH.
W
So
we
is
the
body
and
to
you
of
the
masquerading
Brooke
she
in
the
draft.
So
next
is
the
harbor
service,
ripeness
detection
and
the
condition
of
conditional
advertisement
of
service
segment.
That
means
so
to
achieve
the
redundancy
of
the
services
under
the
SAR
basics
basis.
I
was
training.
We
needed
to
detect
the
down
of
the
services,
but
there's
no.
There
were
no
functionality
so
that,
because
the
current
implementations
focused
on
the
dead
brain
functionality
is,
there
is
no
such
a
control
mechanisms.
W
So
such
a
mechanism
to
detect
the
ripeness
of
the
services
from
the
proxies
are
required
to
practical
practical
deployment,
for
example
integrating
the
basic
prediction,
avoiding
detection
into
the
advertising
cygnets
and
next
he
is
the
hope,
limited
agreement
on
the
SR
basics
proxies
vehicle.
We
notice
that
there
are
a
variance
of
the
decremented
behavior
of
hope
limits
on
the
SRB
is
our
basic
sprocket
unemployment,
a
shindig
meant
the
whole
perimeter
on
the
masquerading
pot
and
and
then
decrement
the
hop
limit
on
the
demonstrating
pot.
W
But
another
implementation
doesn't
decrement
ahora
meet
on
the
most
masquerading
pot
so
but
whom
is
the
correct
behavior?
As
mentioned
in
the
MA
under
under
may
marry
increased
from
transfer,
so
next
the
control
plane
capabilities.
We
we
really
need
control,
plane
capabilities
at
the
at
that
moment,
with
the
devices
do
not
have
the
control
plane
implementations,
because
therefore
they
were
focusing
on
the
the
dead
brain.
So
we
configured
order
service
components
by
our
steps
by
our
hands.
W
It
was
possible,
but
it
was
actually
very,
very
hot,
so
we
strongly
hope
the
functionalities
in
the
control
brain
draft
would
be
implemented
in
the
product,
and
this
is
our
last
final
right,
so
much
condition
for
prying
guess
our
basics
functions.
So
basically,
current
implementations
apprised
our
basics
functions
as
a
result
of
longest
prefix,
much
as
on
the
leading
theories
so
but
in
the
subs
chaining
tranche
to
behaviors
needed
to
be
associated
with
the
default
route,
because
the
packets
from
users
will
have
arbitrary
destination.
W
So
we
need
0.02,
0,
0
or
0
crong
crong
0
structure,
but
so
and
we
need
to
apply
the
different
approaches
for
different
uses.
So
we
see
are
a
pearl
service
chains,
but
so
the
using
the
biographies
are
very
practical
candidate,
but
visitors.
There
is
another
candidate,
for
example,
using
the
BGP
respect
for
so
if
the
BGP
prospect
will
apply,
these
are
basic
functions
as
unction
of
BGP
prospect.
We
can
use
only
one
routing
table
to
apply.
W
W
J
You
for
the
feedback
on
in
general
you're
very
welcome
to
contribute
to
the
mailing
list,
and
especially
if
you
find
the
interrupt
issue,
you
usually
assume
that's
a
specification.
It's
not
clear
enough.
So
you're
welcome
to
send
commands
on
cetera,
if
that's
not
clear
with
on
issues.
So
please
please,
please
contribute
yeah.
Thank
you.
Thanks.