►
From YouTube: IETF114 IDR 20220727 1900
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
A
Straight
in
front
of
me,
okay,
folks,
I
need
help
because
I've
I'm
not
I'm
soft-spoken
anyway.
If
you
can't
hear
me
here
online,
if
you
would,
let
me
know
there'll
be
several
presentations.
A
A
Any
questions
on
the
note.
Well,
okay,
I'm
trying
to
be
short
today,
because
we
have
just
this
one
session,
location,
location,
location.
This
is
location
of
all
the
various
places.
If
something's
not,
there
drop
a
note
online
to
the
chat.
She
was
our
wonderful
working
group
secretary
and
he
will
help
you
bashing
agenda.
If
you
have
a
problem
with
the
agenda,
let
us
know
now,
if
not
we're
going
on
to
document
status.
It's
on
the
wiki.
A
A
A
A
Pardon
it's!
Oh,
I
got
one
more.
Oh,
I
forgot.
I
have
the
first
one,
okay,
guys
and,
ladies
and
gentlemen,
beech
beer
auto
configuration.
We
had
too
little
participation
to
improve
any
of
the
specifications.
A
We
spent
a
lot
of
time
working
on
it
and
then
sort
of
fizzled.
What
happened?
We're
looking
for
feedback
privately
publicly
with
a
wet
noodle?
Shall
we
try
any
of
the
adoptions
again?
Are
you
shall
we
send?
All
of
these
guys?
All
of
the
drafts
off
to
the
independent
stream,
editor
and
alvaro
comes
up
with.
D
Hi,
hello,
thunder
rolling
indy
just
to
be
clear,
it
is
not
an
option
for
us
to
send
anything
to
the
isc.
That
is
a
decision
that
the
draft
authors
will
have
to
make
if
they
want
to
still
publish
the
draft.
The
decision
that
we
can
make
is:
do
we
try
adoption
again?
Do
we
just
not
adopt
them,
but
what
happens
after
the
working
group
is
something
that
we
cannot
decide.
A
A
Yep
interims,
thank
you
folks.
How
many
I
don't
know
if
those
who
are
virtual
tried
to
get
a
time
slot
at
itf-114
tentatively,
we
were
thinking,
we
might
hand
hold
an
interim
in
august
on
the
29th
to
let
those
people
talk.
If
you
are
one
of
those
people
who
didn't
manage
to
get
a
time
slot
today,
if
you
would
please
let
the
chairs
know
or
send
a
note
to
g,
so
we
can
determine
if
we
should
schedule
this
interim
we'll
schedule
others
if
we
need
them
by
topic,
but
nothing
else
is
currently
even
tentatively
scheduled.
D
You
know
I
need
to
give
the
credit
to
john
who
whispered
in.
C
D
Ear
and
said,
go
say
this
so
better.
E
You
please
go
ahead
and,
let's
not
see
me
hello,
everybody
yeah!
This
is
an
update
about
the
bgp
extension
for
advertising.
I
feed
capabilities
that
the
draft
has
been
recently
adopted,
I'm
giuseppe
and
I'm
presenting
on
the
alpha
quarter.
So
next
slide
just
a
few
words
about
the
background
and
motivation.
E
So
if
it
stands
for
in
c2
for
information
telemetry-
and
it's
just
an
aim
to
refer
the
data
plane
on
path,
telemetry
techniques,
including
in
situ
im
defined
in
the
rfc
9197
and
alternate
marking
defined
in
the
rfc
83
21
and
88
89,
and
we
are
currently
working
to
the
beast
document
to
elevate
this
methodology
to
propose
a
standard.
E
Since
these
are
solutions
requiring
into
limited
domains,
it
is
required
that
the
ingress
node
learn
the
effect
capability,
supported
by
the
end
node,
in
order
to
avoid
data
leaking
from
the
domain.
So
in
this
way
we
need
to
define
an
a
mechanism
and
an
extension
to
bgp
to
advertise
the
feed
capabilities.
E
E
So
the
bgp
next
top
capability
attribute
is
defined
in
another
document.
It
is
the
next
top
capability
draft.
E
This
next
top
capability
is
a
non-transitive
bgp
attribute,
and
the
important
characteristic
is
that
it
is
updated
or
deleted
when
the
next
stop
is
changed.
This
is
an
important
characteristic
because
it
guarantees
for
the
limited
domain
application
that
when
the
next
stop
change,
also
the
capability
reflect
the
next
stop.
E
E
E
E
In
case
of
multiple
domain,
they
can
still
build,
let's
say,
a
controller
domain,
and
in
this
case
the
routing
the
router
reflector
may
also
pass
this
information
between
different
clusters
to
keep
the
effect
methods
consistent
between
different
domains.
Next
slide,
yeah
just
few
words
about
the
the
the
ongoing
discussion.
E
So
during
the
adoption
there
were
several
comments
that
were
already
addressed
in
the
latest
version.
In
particular,
I
want
to
highlight
that
it
has
been
clarified
that
the
only
solution
in
scope
is
the
next
stop
capability
attribute,
as
since
it
is
a
non-transitive
attribute.
E
Also,
I
want
to
thank
you
for
opening
a
discussion
with
the
ippm
working
group,
so
we
received
also
some
feedback
from
the
ippm
working
group
and
the
this
feedback
will
be
addressed
in
the
next
version,
in
particular
a
clarification
about
the
use
of
the
term
I
fit
and
most
important
relationship
with
draft
in
ippm
about
the
iom.
Conf
state,
so
it
is
a
similar
mechanism,
but
it
use
icmp
v6.
So
we
have
to
distinguish
the
scenario
when
bgp
is
the
best
option
and
other
cases
where
icmpd6
can
be
used.
E
E
G
All
right,
this
is
mahesh
jaitanandani,
I'm
here
to
present
a
status
on
the
bgp
yang
model.
Next
slide,
please
all
right
the
status
with
the
dash
14
version
of
the
draft,
a
lot
of
cleanup
on
the
draft,
mainly
to
move
the
stats
for
total
parts
and
prefixes
into
its
own
container,
the
stats
container
and,
more
importantly,
clean
up
the
use
of
counters
and
consistency
in
its
use
across
the
entire
draft.
G
G
So
we
had
I
put
forth
the
proposal,
but
after
looking
at
it
the
second
time,
we
decided
that
we
need
to
make
changes
to
the
tcp
yang
model
and
the
changes
for
which
were
proposed
in
tcp
by
the
way.
That
model
is
an
isc
discussion
right
now
and
essentially
that
augments
the
keychain
model
and
provides
the
ability
for
bgp
to
just
make
a
call
to
say
that
it
wants
to
secure
its
the
particular
session
or
not.
G
G
G
We
are
now
down
to
issues
related
to
policy
configuration
and
we
need
to
do
that
clean
up
in
the
in
the
next
phase
next
slide.
G
G
H
H
However,
standard
does
not
exist
for
connecting
ipv4
islands
over
an
ipv6
core,
so
this
draft
provides
a
specification
for
connecting
ipv4
albums
over
an
ipv6
core,
as
I
as
operators
migrate
to
a
single
vertical
ipv6.
Only
core
you
know,
per
rfc
5565
software
mesh
framework
involves.
You
know,
six
to
four
tunneling
of
six
packets
over
a
four
core
called
6p.
Now,
with
this
draft,
a
similar
four
to
six
tunnel
of
ipv4
package
over
over
an
ipv6
core
can
now
can
now
be
instantiated
now
called
4pe.
H
The
name
for
6pu
is
termed
that
way
for
tunneling
ipv6,
labeled
packets,
over
ipv4
and
now,
similarly
with
4p,
the
term
finds
the
tunneling
of
ipv4
packets
over
a
ipv6
core
next
slide
so
for
pe
architecture
and
overview
so
4p
roughly
it
so
sorry,
4p
routers
exchange,
ipv4,
reachability,
transparently
tunneled
over
an
ipv6
core
using
multi-particle
bgp
rfc
2545
using
bgp.
Next
stop
field
conveyed
conveyed,
conveying
the
ipv6
address
to
the
4pe
router
so
that
the
dynamically
established
ipv6
signaled
lsp
can
be
can
be
utilized
without
explicit
tunnel
configuration.
H
So
this
is
basically
the
say,
the
signaling,
the
top
most
transport
label
and
then
4p
uses
rfc
85.
It
uses
rrc
8950
next
hop,
encoding,
16
or
32
by
next
top
for
a
ipv6
address,
slash,
link,
local
address,
ingress
and
eager
sp.
Routers
must
bind
the
labeled
label
to
all
ipv4
presses,
bgplu,
rfc
8277
and
then
four
pe
supports
explicit
null
signaling
for
disk
serve
pipe
mode,
a
model
rfc
3270
and
then
4p
supports
rfc,
4364,
nras
options,
a
b
cnab
as
well
as
4p
design
as
well
supports
three
data.
H
So
this
is
a
just
a
graphical
depiction,
so
this
is
with
six
pe.
So
basically,
you
have
really
there's
there's
two
main
components:
one
is
signaling
this,
the
transport
layer,
transport
lsp
over
an
mpls
core
and
that's
that's
shown
signaling
from
the
ingress
pe
to
the
egress
pe
building
that
lsp
and
then
bgplu
labeling,
the
ipv6
prefixes,
all
prefixes
that
are
advertised
from
the
cdp,
labeling
them
with
six
for
six
on
the
6p
router
propagated
the
control
plane
propagated
from
ingress
to
egress
next
slide
so
with
four
pe.
H
Similarly,
and
an
mpl
scored
the
egress
ingress
pe
signals
and
and
establishes
a
transport
lsp,
an
ipv6
lsp
across
the
ipv6
core
and
then
as
well.
The
service
service
label
bottom
of
stack
bgplu,
all
the
v4
prefixes
are
have
a
label
binding
and
and
advertised
across
the
control
plane
from
ingress
p
to
eager
spe
next
slide.
H
Similarly,
with
srm
pls,
if
you
have
let's
say
a
centralized
controller,
where
you're
building
the
srte
path,
instantiating
that
path
to
your
egress
pe,
your
transport
would
be
built
across
the
core
from
ingress
to
egress,
to
your
to
your
node
sid
on
the
egress
side,
and
then
your
vpns,
your
bottom
of
stack
service
label
with
bgplu.
H
That
piece
all
remains
the
same:
there's
no
change
from
mpls
to
srm
pls.
Just
the
transport
piece
changes
next
slide
with
srv6
rfc
9252
bgp,
srv6
services,
bgp
prefix
sit
attribute
so
here
the
srl
sr
v6
l3
service,
tlv,
bgp
label
transposition.
So
this
is
where
the
transposition
happens
to
the
function.
Slash
argument
field,
so
that's
defined
in
section
5.3
in
in
that,
in
that
our
in
that
rfc
and
then
rfc
8986,
the
r76
programming
draft
section
4.7,
I'm
not
I'm
out
of
pine.
Okay,
all
right!
So
so!
H
Basically,
here
the
the
transport
labels
is
built,
the
controller
instantiates,
the
transport
tran
transport
path
across
the
core
and
then
the
vpn
service.
The
bottom
of
stack
service
labels
are
basically
is
exactly
the
same
as
the
mpls
as
as
well
as
srm
pls
the
binding
bgp
lu
for
the
control
plane,
binding
of
all
the
v4
prefixes
across
the
core.
We
can
just
go
to
the
last
slide.
H
Just
yeah
called
it
at
the
last
slide,
so
I'm
so
I'd
like
to
solicit
the
idr
workgroup
for
feedback
and
comments
on
the
draft,
and
thank
you
very
much
thanks.
A
Okay,
dj:
will
you
test
your
mic
before
we
begin
and
colorado
nats?
If
you
would
come
to
the
front?
Okay,
I'm
gonna
start
talking.
While
you
move
okay,
this
is
the
summation
gotta
get
the
house
how's
the
sound,
okay,
folks,
okay,
thank
you
very
much
jeff
and
the
rest.
The
car
ct
adoption
call.
Our
presentation
is
from
dj
and
colorads
and
nats.
A
I
don't
swadesh
may
add
in
go
ahead
jeff,
so
the
adoption
call
went
from
just
after
july,
6
to
july
27th
we
had
a
tremendous
amount
of
people,
respond,
lots
of
wonderful
input
and
about
last
week
I
sort
of
summarized
what
I'm
going
to
say.
Next,
that
the
chairs
were
heading
toward
the
idr
wiki
has
summaries
and
notes.
I
because
it
was
a
lot
of
input.
I
wrote
up
notes
you
can
find
that
on
the
idr
wiki
go
ahead.
A
One
thing
that
really
helped
us
is:
we've
got
a
lot
of
input
and
detailed
input
from
folks
who
were
customer
support
people
and
we
use
that
to
gauge
customer
and
we
had
a
lot
of
really
off
channel
and
on
channel
input
from
operators.
What
we're
going
toward
is
maybe
not
a
perfect
solution,
but
we're
going
to
take.
The
two
drafts
is
on
the
experimental
track
and
we'll
generate
as
a
working
group,
an
interoperability
document
between
the
two.
A
A
There
is
a
concern
that
we
need
to
make
sure
the
error
handling's
well
done
and
that
everything
is
specified
for
the
environments
it's
going
to
go
to
now.
The
benefit
that
I've
asked
the
authors
to
provide
is
I've
asked
them
to
describe
some
of
their
deployment,
use
cases
and
that's
not
all
the
possible
ones,
but
I've
asked
them
to
pick
up
one
or
two.
A
The
ex
one
question
I've
had
from
several
people
is:
how
do
you
go
from
experimental
to
propose?
Well,
after
you
revise
and
get
that
critical
customer
feedback,
because
you've
been
in
the
field,
we
can
revise
the
draft
or
say
perhaps
that
it's
perfect
and
turn
it
into
proposed.
Now
I
must
suspect
that
alvaro
and
other
isg
members
would
like
to
see
an
interoperability
between
these
two
drafts
and,
as
always,
it
is
an
idr
draft,
so
it
will
be
two
implementations
at
this
point.
A
We
believe
we
will
request
two
implementations
for
each
draft,
but
again
we
will
take
this
to
the
working
group
now
for
our
topics.
For
this
conversation,
we're
going
to
go
through
the
customer
examples,
the
issues
that
were
raised
on
part
three
of
the
adoption
call
the
car
next
steps.
A
F
F
Sure,
thank
you.
So
I
I'll
do
a
brief
overview
of
a
fairly
typical
deployment
scenario.
This
is
not
tied
to
a
specific
customer.
I
mean
we
generalized
it
and
in
general,
the
pattern
you
know
repeats
across
many
customers
that
are,
you
know
looking
at
this
solution,
so
this
base
use
case
is
for
establishing.
You
know
different
multiple
intent,
aware
paths
to
a
specific
router
in
the
network,
most
likely
pe.
You
know
the
pe
loopback
and
the
the
the
plu
bag
is
actually
the
bgp
next
hop
of
a
service.
F
So
obviously
the
service
can
be
l3
vpn.
In
many
cases,
and
often
it
is
the
global
table
and
then
also
you
know
more
recently
evpn.
So
these
are
the
typical
cases
that
we
have
from
a
service
point
of
view
and
when
it
comes
to
intent
again,
there's
different
types
of
intent
that
we
are,
you
know,
seeing
you
know
likely,
there's
obviously
low
latency
we
have
avoidance,
is
a
you
know
popular.
You
know,
use
case,
there's
you
know
things
like
diverse
paths,
etc.
F
So
most
of
these
fall
into
the
same.
You
know
pattern
that
you,
you
know
for
a
pe.
You
can
have
more
than
one
intent
at
the
same
time.
You
know
where
you
need
colorado
paths
and
you
know
we
need
to
support
that
across
a
multi-domain.
You
know
environment
where
bgp
is
used
again.
I've
shown
a
single,
you
know
simple
topology,
but
in
reality
we
do
see.
You
know
variations,
you
know
both
multi-as
and
multi-igp
and
then
again
you
know
for
the
purpose
of
this
talk.
F
I
you
know
just
the
you
know
a
common
case
that
we
see
you
know
in
many
scenarios
where
we
have
igp
flex,
algo
being
enabled
in
the
you
know
in
the
respective
domains
for
providing
the
intra-domain
intent.
But
again
there
is
variation
there
in
you
know
cases
where
we
have
existing
networks.
We
see
things
like
rsvpte.
F
In
some
cases
we
even
have
you
know
need
to
go
over
a
bgpalu
island.
So
you
know
in
general,
all
these
cases
are
covered
in
the
draft,
but
you
know
here
I
just
picked
sort
of
one.
You
know
sort
of
simple
scenario.
F
Another
you
know
case,
which
sort
of
details
into
the
one
that
we
you
know
saw
earlier
is
in
in
the
multi-domain
environment.
We
very
often
have
the
case
where
not
all
domains
have
the
same
number
of
colors,
or
you
know
intents
that's
what
we
you
know
refer
to
in
the
bgp
card
draft,
as
the
n
is
to
m
mapping.
So
you
know
here
we
see
a
very
typical
example
where,
in
the
core
you
can
have
more.
You
know
colors,
so
you
know
shown
four
in
this
example.
I
F
The
you
know
between
say
a
pair
of
pes.
So
again,
as
you
see
in
this
example,
there's
four.
I
F
C1
c2,
c3
and
c4,
for
you
know
specific.
You
know
egress
v
e3.
When
those
routes
go
across
this
multi-domain
network,
they
do
need
to
map
to
the
respective.
You
know,
one
of
the
available
intra-domain
intents
and
and
that
is
handled
in
bgp
car.
By
leveraging
the
same.
You
know,
mechanism
that
we
have
for
self
steering
today,
where
the
color.
F
Community
is
used
to
steer
service
routes
through
a
particular
color
aware
transport
path,
the
same
way
when
it
comes
down
to
this
second
layer
of
resolution,
a
color
external
community
on
the
bgp
car
route
allows
for
you
know,
resolution
into
a
specific
intra
domain
intent
again.
F
Are
in
the
in
the
draft
next
next
slide,
please
now
here
we
have
a
slightly
different
case
where,
instead
of
having
a
color
aware
path
to
a
specific,
you
know,
router,
what
we
have
here
is
traffic
that
needs
to
be.
You
know,
sent.
I
I
F
Nodes,
you
know
that
offer
a
kind
of
any
cast.
You
know
service,
so
here,
instead
of
it
being
single,
you
know
p
loop
back
ip
here
we
have
a
an
anycast
ip
and
you
know
color.
That
goes
along
with
it
that's
advertised
by
a
set
of
nodes
which
can
be
in
the
same
or
multiple
domains
and
in
terms
of
traffic
forwarding
you
know
to
from
different
ingress
nodes
to
you
know
this.
These
set
of
nodes.
F
The
base
scenario
is
where
you
have
the
network
providing
and
any
cast
forwarding
mechanism
where
traffic
goes
to
the
nearest
set
of
nodes.
In
this
example,
we
have
traffic
from
e11
landing
on
the
nodes
in
you
know,
domain
four,
whereas
you
know
the
traffic
from
e
to
one
being
load
balanced
across
the
the
nodes
in
domain.
You
know
five
and
six
is
just
an
illustration
again.
There
is
there
are
variations
here.
F
One
you
know
typical
variation
is
where
it
is
the
ingress
pe
which
you
know,
does
the
explicit
load
balancing
across
the
set
of
available.
You
know
egress
domains.
One
thing
to
mention
is
in
in
this
sort
of
case.
It's
the
expectation
is
that
any
of
these
nodes
that
receive
the
traffic
are
capable
of
forwarding
the
the
actual
you
know,
payload
most
more
likely
a
sort
of
a
global
table.
F
K
Hello
yup,
so
we
are
going
to
describe
the
use
cases
that
we
are
seeing
for
bgpct,
and
these
are
a
few
use
cases
which
can
be
classified
as
the
basically
whatever
use
case.
We
are
seeing.
We
just
classified
a
few
types
of
them
and
we
have
listed
the
customers
in
some
cases
wherever
it's
possible.
K
So
this
is
the
first
use
case
where
you
see
two
domains
which
are
using
their
own
intra
domain
transfer
protocols,
and
these
are
like
existing
deployments,
which
may
use
like
rsvp
in
both
the
domains,
and
some
of
them
may
be
moving
to
srt
in
some
of
the
domains.
So
this
is
a
typical
deployment
scenario
that
we
are
seeing
where
customers
want
to
offer.
End-To-End,
sla
and
bgpct
is
able
to
help
them
with
this.
K
K
So
this
is
another
example
where
the
flow
based
forwarding
that
using
bgp
flow
spec
if
they
want
to
be
given
a
certain
sla
and
how
does
that
work?
So
we
just
have
the
service
chain
element
that
is
being
advertised
in
bgpct
with
a
different
transport
class
and
those
transport
classes.
They
resolve
over
the
tc100
tunnels
that
are
there
in
the
core
and
the
bgp
flow
spec
routes.
K
They
just
carry
the
redirect
to
ip
next
hop
with
the
transport
class
so
with
with
a
color,
and
that
allows
them
to
resolve
the
flow
spec
route
over
the
certain
transport
class,
which
can
be
rsvp
srt
or
any
any
kind
of
tunnel
again.
So
this
is
just
a
typical
flow
spec
example
which
carries
the
color
community
and
it's
able
to
put
traffic
over
a
certain
sla
next
slide,
please.
K
K
So
if
you
think
about
it,
the
the
flowspec
example
or
this
non-agreeing
color
domain
and
heterogeneous
color
example,
so
we
the
bjpct
solution.
It
just
has
base
transport
tunnels
which
are
of
a
certain
color,
and
it
automatically
creates
the
resolution
schemes
for
that
color
color
100
in
this
example,
and
whenever
you
have
another
color
route
like
101
102
in
the
flow
spec
example,
or
this
compound
color
in
100
200.
K
In
this
example,
we
will
just
map
it
using
custom
resolution
schemes
to
the
transport
tunnels
that
are
available,
the
transport
colors
that
are
available
in
that
domain,
so
the
service
routes
or
the
other
transport
routes,
they
can
resolve
using
custom
resolution
schemes
through
the
transport
terminal.
So
this
is
overall
how
the
whole
bgbct
thing
works.
A
Okay,
then
it's
my
turn.
There
are
issues
that
you
will
have
seen
on
the
third
part
of
the
adoption
call.
We
tried
to
keep
the
adoption
call
with
imp,
requesting
information
requesting
call
for
adoption
and
then
issues
with
either
draft.
A
F
Oh,
thank
you.
So
in
general
we
have
gotten
a
good
amount
of
feedback
from
various
collaborators
on
and
off
the
list,
and
you
know
that
has
helped
the
the
you
know
the
car
document
to
get
to
the
current
version.
F
You
know
again,
we
would,
you
know,
request
wider,
you
know,
review
and
and
feedback
on
the
current
version
and
at
the
same
time
there
are
certain
you
know
areas
that
we
intend
to
update
on
the
you
know
in
the
next
couple
of
versions,
so
a
couple
of
key
ones
being
detailing
the
srv6,
related
flows
and
some
considerations
and
then
updates
on
the
filtering
mechanisms
to
be
used
for
bgp
car.
F
So
we,
you
know
again
request
you
know,
folks,
to
help
with
that
and
also
provide
you
know:
additional
input
on
other
use
case
scenarios
to
make
the
draft
complete.
Thank
you.
A
I
Sure,
first
of
all,
thanks
for
adopting
bgbct
and
my
best
wishes
to
php
card
team
as
well.
So
the
first
things
we
need
help
with
is
to
clarify
text
for
disallowing
srv6
transposition
for
sophie
76.
I
So
this
is
something
that
we
will
do
in
the
next
four
months
and
the
next
one
is
text
clarification
for
section
8
for
usage
of
rd.
There
has
been
some
back
and
forth
on
part
3
about
this,
and
we
have
taken
an
action
item
to
clearly
list
the
flexibility
of
using
the
same
rd
versus
unicardi
and
the
different
label
allocation
modes
that
are
available
in
bgpct.
I
So
to
address
all
the
scenarios
that
have
been
pointed
out
in
part.
Three
then
there
is,
there
is
a
point
about
expressing
and
processing
customer
intent,
which
is
on
the
cep,
links
so
which
is
analogous
to
vpn
car.
So
here
we
have
to
add
text
for
control
plane,
as
well
as
data
bring
procedures,
control,
plane
procedures
are
for
mapping
signaling
the
customer
entrant
from
cpe,
some
p
to
c,
and
then
the
data
plane
procedures
to
map
the
customer
intent
coming
from
the
ce
on
to
the
pe.
I
So
this
the
idea
is
to
actually
not
use
a
new
fisafi
but
handle
it
within
the
attributes
and
for
the
use
cases
that
we
have
projected
a
little
earlier
we'd
be
we
have
some
backup
slides
to
explain
those
use
cases
in
details.
So
if
you
do
want
to
take
a
look
at
those
use
cases
yeah
please
help
yourself.
I
think
that's
about
it.
A
Thank
you,
matt.
Okay,
the
interoperability
document
we're
going
to
look
to
see
if
we
can
find
a
path
to
interoperable
features
or
our
big
picture
questions
that
we
received
input
on.
What's
a
color
for
color
in
the
nri,
not
in
the
nri
impact
of
packing
and
translation.
Now
this
to
me
is
an
important
piece,
because
the
use
cases
suggest
they
will
be
used
in
some
5g
network,
so
packing
and
packing
is
important
both
in
the
nri
and
in
the
attributes.
A
A
What
I
heard
from
some
of
the
providers
is
their
need
for
filtering
or
aggregation
in
their
policies,
even
in
the
color
situation,
the
expression
of
transport
intent
as
inter
asbpn,
you
will
note
we
had
discussions
on
type
a
type
b
and
type
c,
we'll
need
to
talk
about
this
as
a
working
group
to
sort
of
set
our
bar
for
this
upcoming
set
of
work.
Now
today,
a
couple
authors
told
me
that
they
had
a
color
draft
for
srv6,
that's
nice,
but
we
need
to
guide
this
work
in
one
way.
A
A
Jeff
I've
stole
this
from
jeff
because
he
did
a
lot
of
the
foundational
work
for
the
chairs
determining
that
these
are
functionally
equivalent.
I
don't
think
the
call
has
changed
our
attitude
at
all
that
these
are
functionally
equivalent
and
operationally
different.
So
take
a
look.
This
is
eye
candy
or
study
it.
This
is
the
car
and
lcm
community
go
ahead
to
the
next.
This
is
the
ct
lry
and
transport
community
extended
community.
We
will
need
to
talk
about
how
interoperability
works
as
a
working
group.
A
These
are
now
going
to
become
working
group
documents
and
we
will
work
on
them.
There
are
implementations
in
play
so
folks,
that's
the
end
of
our
presentation.
As
it's
been
a
active
working
group.
Adoption
call
now
is
the
time
for
questions
online
or
in
person.
If
you
would
step
to
one
of
the
two
mics
and
let
us
know
if
we
can
provide
you
more
details,.
L
So
you
said
in
the
preamble
that
deployment
is
more
important
than
interpret
interoperability
at
this
point,
but
you
talk
about
the
interoperability
document.
Is
it
not
important
to
give
a
deployment
experience
after
a
while
to
say
you
know?
Is
it
fit
for
purpose,
for
whatever
people
want
to
do
with
it?
L
A
So
let
me
rephrase
frame
your
question
if
I
may,
to
make
sure
I
understand
it
first
you're
asking:
should
we
define
what
it
is
supposed
to
do
as
well
as
interoperability
and
that's
a
really
good
question?
Here's
the
reason
we
hadn't
charged
with
both
feet
into
that
direction,
is
that
spring
is
working
on
something
in
this
area
and
there
is
still
at
the
individual
draft,
so
we're
sort
of
waiting
to
see
it
does
have
input
from
both
sets
of
authors.
A
A
Folks,
after
all,
the
talking
on
the
mail
list
have
we
run
out
of
steem
grady.
Thank
you
for
being
asking
one
of
the
really
good
questions
that
that
excellent
question
probably
should
have
put
it
in
my
notes,
but
excellent,
because
we
need
to
know
where
we're
going.
The
adoption
calls
were
like
taking
a
term
paper
because
we
need
to
know
where
we're
going
any
more
questions
to
those
in
the
online
scenario.
C
C
I
think
that
the
core
three
question
threads
have
come
to
conclusion
at
this
point,
so
please
feel
free
to
start
completely
separate
threads
you're,
absolutely
encouraged
to
ask
hard
questions.
Technically.
You're
also
required
to
be
respectful
as
part
of
those
questions
and
they'll
stick
to
technical
observations.
A
And
go
ahead
and
queue
up
to
the
mic,
and
I'm
going
to
make
one
comment.
Thank
you
for
everyone.
During
the
last
couple
weeks,
when
I
said
please
move
to
four
and
three
in
technical
questions,
we
will
probably
for
this
topic,
try
to
have
the
level
of
detail
that
we
had
in
forum
three.
If
you
have
any
questions
on
how
to
do
that,
just
drop
a
note
to
the
chairs
we'll
be
glad
to
help
you
go
ahead.
Grady.
L
Hi
kiriti
compiler,
so
the
interoperability
report
is
there
an
implication
by
having
that
that
eventually
both
will
become
standards
or
are
we
even
thinking
is?
Am
I
jumping
the
gun
on?
That?
Is
one
going
to
become
a
standard
and
one
going
to
go
away.
A
So
creedy,
if
I
had
all
of
those
answers,
I
would
have
given
them.
The
answer
is
I'm
taking
them
forward
to
I've
listened
to
the
customers
and
they've
said
what
I
reported.
I
believe
that
these
folks
will
take
their
thing
all
the
way
to
experimental
this.
Some
questions
have
been.
How
is
there
a
quick
term
from
experimental
to
proposed?
A
Probably
because
these
are
fairly
well
developed
works?
The
experimental
is
because
I
wasn't
as
the
chair
who
is
neutral
chartered
with
shepherding
this.
I
couldn't
see
where
we
really
had
enough
clear
consensus,
one
way
or
the
other.
I
think
if
you
watch
the
list
in
my
reports,
you'll
saw
that
it
it
isn't
clear
one
way
or
the
other,
but
the
customers
really
said
in
each
of
the
cases.
I
really
want
that
and
we've
had
dual
setups.
In
fact,
you
saw
a
couple
of
the
customers
say.
A
C
So,
greedy,
partially
to
your
point,
you
know
we
have
more
than
one
place
in
ietf,
where
more
than
one
technology
has
come
out
covering
a
given
space.
You
know
we
have
examples
that
multicast
we
have.
You
know
examples
in
l2
as
you're
aware
of,
and
what
we're
probably
looking
at
you
know
is
what
the
interrupt
probably
means
in
the
short
term
is:
how
do
you
make
these
technologies
interact
together
in
the
same
network?
C
So
customers
can
solve
their
problems
when
you
know
one
solution
may
be
appropriate
and
you
know
the
solution
is
appropriate
for
different
spot.
So
that's
that's
the
short-term
goal.
If
it
turns
out
that
we
eventually
converge
on
when
solutions
appropriate
for
everything,
that's
how
this
will
settle
out.
A
Actually
add
a
question
and
then
vim
so
guys,
properness
shortness
in
the
question
would
be
helpful.
H
A
H
Wish
I
had
a
better
answer
and
I
guess
it's
possible
that
I
think,
as
you
go
through
the
experimental
and
as
both
solutions
are
quite
different,
that
that
you
know,
even
though
we
want,
but
if
there's,
if
the
interoperability
is
not
feasible,
would
they
just
still
both
be
able
to
progress?
I
guess
to
rfc.
A
M
Yeah
remembering
yeah,
I
find
the
process
a
little
bit
strange,
if
I'm
honest,
because
if
we
seek
for
feedback
from
operators
who
are
going
to
deploy
experimentally,
which
operator
is
going
to
try
both.
Do
we
have
one
that
is
going
to
do
that?
Because
what
I
my
fear
is
what
will
happen
is
operator
a
deploys
a
and
he
will
say
I
want
a
operator
b
deploys
b
and
he
will
say
I
want
b
and
we
will
not
going
to
come
to
a
conclusion
on
converging
towards
a
single
solution.
I'm
afraid
I
share.
F
M
So
so
here's
my
proposal
is
there
no
way
like
to
basically
come
up
with
a
let's
say,
independent
team
which
basically
take
people
from
the
various
solutions
in
it
and
try
to
come
to
a
convert
solution
rather
than
what
we
are
doing
right
now,
because
I
feel
that
we
are
not
converging
because
if
you
talk
about
interop,
if
you
look
to
both
of
the
things,
although
they
try
to
achieve
the
same
thing,
they
are
incompatible
right
now.
So
the
way
to
do
interop
is
you
have
to
deploy
a
gateway.
M
M
If
I
deploy
a
in
my
live
network,
I'm
not
going
to
change
to
b,
I
will
keep
a
and
that's
a
bit
the
fear
I
have
with
the
with
the
proposal
that
we
have
or
the
consensus
that
we
reached
here
today
in
the
work
group.
I
don't
know
what
other
things,
but
that's
my
personal
view.
A
H
H
So
the
motivation
of
this
presentation
is
to
summarize
updates.
We've
had
a
lot
of
feedback
from
the
work
group
and
we
believe
we've
resolved
all
all
the
issues
that
have
come
up
over
the
previous
adoption
calls
as
well
as
feedback
over
the
it
seems
like
a
last
year
or
so
so
here
we're
going
to
describe
just
all
the
updates.
So
the
first
one
is
we,
the
permit.
H
All
mechanism
is
defined
as
a
set
of
a
set
sequence
to
the
all
fs
and
then
set
rd
to
zero
trigger
the
vpn,
prefix
or
f
mechanism
has
been
clarified.
Operational
process
of
the
vpn
or
f
or
receiver
has
been
updated
to
now
use
a
three
tuple.
So
previously
it
was
just
an
rd
and
we
did
have
a
lot
of
feedback
from
the
work
group
related
to
using
rd
for
filtering
and
issues.
H
So
that
has
changed
to
now
being
a
three
tuple
rd
source,
pe
and
rt
of
the
vpn
route,
and
it's
extracted
from
the
bgp
update
source
petl
to
define
the
identity
of
the
source
of
the
vpn
routes.
We're
set
to
a
next
top
community
for
option
c
for
enter
domain
scenario
and
then
set
to
source
p
extended
community
for
option
b,
where
the
next
stop
is
change.
H
H
I've
gone
to
the
next
slide
after
that,
so
now
we're
at
the
point
just
comments
and
feedback
from
the
work
group
of
any
other
questions
or
outstanding
anything
outstanding.
We
would
like
the
work
group
to
provide
us
any
anything
outstanding
feedback,
and
then
we
would
like
to
prepare
to
proceed
to
a
to
another
adoption
call.
Thank
you.
A
B
Hello,
everybody
it's
nice
to
be
on
this
side
of
the
mic
as
an
individual
contributor,
so
this
is
work.
That's
been
discussed
in
the
list
a
while,
and
but
we
went
through
a
quick
name,
change
and
added
a
number
of
authors
who
provided
some
very
useful
feedback
about
how
this
thing
is
going
to
be
deployed
in
a
multi-vendor
way
in
people's
networks.
Next
slide,
please
so
just
quick
background.
B
In
the
beginning
was
our
well
actually
in
the
beginning,
we
didn't
have
a
good
way
of
signaling,
entropy
and
networks,
and
that
wasn't
good
for
reasons
having
to
do
with
it's
important
to
be
able
to
make
use
of
all
the
links
in
your
networks,
and
it's
become
increasingly
important
to
be
able
to
make
use
of
all
those
parallel
links.
We
have
rfc
6790.
That
tells
us
how
to
do
it.
It's
very
nice.
B
It
specifies
in
order
to
do
this
properly.
We
need
to
be
able
to
signal
from
you
know,
egress
to
an
ingress
and
say
hello.
I
can
actually
parse
and
use
your
entropy
labels.
B
Now
6790
told
us
how
to
signal
that,
in
a
bunch
of
different
protocols,
one
of
them
was
bgp
had
a
very
picked,
a
very
simple
solution,
which
is
just
here.
I've
got
a
an
attribute:
it's
called
entropy
label
capability,
but
it's
not
a
bgp
capability.
B
It's
an
attribute,
and
it's
just
this
little
dataless
attribute
the
type
code
is
all
all
that's
there.
Really
it
tells
you
hey.
I
know
how
to
do
entropy
labels.
That
was
great.
There
was
only
one
little
problem
with
it.
The
rfc
tells
us,
for
heaven's
sakes,
don't
leak
this
thing
outside
of
your
domain.
By
the
way
it's
optional
transitive
next
slide,
please
so.
B
Yeah
we
actually
did
we
no
never
mind
so
we
developed
a
sorry
somehow
I've
rearranged,
my
slides,
yeah
anyhow,
the
the
leaking.
The
attribute
thing
was
something
we
needed
a
solution
to.
We
developed
a
solution
to
this
thing
and
kind
of
forgot
to
s.
B
Tell
the
world
about
it
and
kind
of
reused,
attribute
28,
and
we
feel
very
bad
about
this.
It
wasn't
on
purpose,
we're
sorry,
so
the
current
draft
is
basically
the
same
thing
that's
already
deployed
on
in
junos,
but
we
have
sort
of
been
beaten
into
admitting
that,
yes,
we
really
should
request
a
fresh
code
point
for
this.
The
the
beatings
were
not
very
difficult.
I
mean
it
was
pretty.
Obviously
the
right
thing
so
and
you
know
obviously
that
addresses
then
concerns
about
sharing
the
code.
Point
next
slide.
Please.
B
No,
not
that
one,
but
if
you
haven't
signed
in
scan
that
qr
code
I'll
just
tell
a
few
jokes
while
the
the
okay
here
we
go
yeah.
So
no,
the
this
slide
is
fine.
I
I
had
a
funny
little
build,
but
you
can
just
go
ahead
and
go
to
the
last
one.
So
right
just
to
to
you
know,
give
a
quick
outline
of
of
the
solution.
As
you
recall,
I
said
the
previous
version
was
a
dataless
attribute
and
we,
you
know,
talked
amongst
ourselves
about
well.
B
One
of
them
is
the
thing
shouldn't
leak
and
the
other
is
that
it
shouldn't
require
a
forklift
of
your
route,
reflector
infrastructure
in
order
to
deploy
it
and
that
you
know
the
the
the
bottom
one
comes
from
the
laws
of
physics
and
the
top
one
or
sort
of,
and
the
top
one
comes
from
strong
input
from
network
operators
that
have
constraints
in
how
they
deploy
code
in
their
networks
so
being
able
to
deploy
across
older
route.
Reflector
installations
implies,
you
need
optional.
Transitive
not
leaking
implies
not
having
optional
transitive.
B
So
doing
no
harm
ended
up
looking
like
well.
What
if
we
take
the
the
next
hop
and
just
copy
it
into
data
that
is
in
this
attribute
and
then
say
right
if
I'm
a
receiver-
and
I
get
this
thing,
I
take
a
look
at
the
next
hop.
I
take
a
look
at
the
data
in
the
attribute.
Are
they
the
same?
Okay?
That
means
that
nobody
has
molested
this
thing.
B
As
it
comes
towards
me,
I
can
be
fairly
sure
that
the
the
the
router
that
sent
me
this
attribute
really
can
handle
after
handle
entropy
labels,
as
as
it
promises
to
if
they
don't
match
you
take
the
thing
you
throw
it
out
next,
please,
it's
probably
faster
to
read
the
draft
than
to
listen
to
me
talking
about
it's
a
very
short
draft,
so
we
had
some
good
discussion
about
this
on
the
list.
As
I
said,
we,
you
know
in
part,
were
jawboned
into
moving
to
a
new
code.
B
Point
bruno
suggested
allowing
trailing
data
just
in
case.
We
want
to
do
something
else
with
this
in
the
future
seems
reasonable
and
we've
also
been
asked.
You
know,
oh,
you
really
should
put
in
some
considerations
for
how
this
thing
interoperates,
with
the
thing
that
you
already
have
in
the
field,
and
I
think
it
makes
sense
to
put
in
a
section
about
that
too.
So
very
soon,
we'll
publish
a
version
of
one
that
that
has
at
least
those
two
things,
and
you
know
if
anybody
is
looking
for
something
else.
B
Right,
so,
what's
next
in
no
particular
order,
we
will
publish
a
version.
One
we'd
also
like
to
have
this
adopted
by
the
working
group.
B
There's
you
know
a
fairly
obvious
need
to
have
a
standardized
solution
here
and
we've
got
some
deployment
experience
that
says
this
thing
works
in
the
field
and
we'd
like
to
you
know,
come
clean,
get
it
standardized,
get
get
it
out
there
and
get
it
done,
so
my
hope
would
be
to
adopt
it
and
then
fairly
quickly.
Move
to
working
group
last
call
and
looks
like
we
have
38
seconds
for
questions.
Any
questions.
G
B
So
that
is
a
very
interesting
point
and
we'll
put
that
in
the
security
considerations
in
the
next
version
and
also
give
it
a
bit
of
a
think
to
see
if
we
can
do
any
better,
but
it
at
least
belongs
in
the
security
considerations.
Thank
you
for
pointing
it
out.
C
C
Okay
thanks
john
next
presentation
is
bgbsr
policy;
extensions,
actually,
sorry
that
one's
g
that
one's
deferred
to
land,
the
next
one
is
beach.
Bls
extensions
for
sr
network
resource
ran
chen.
O
O
O
O
O
We
defined
we
define
an
api
dtr
way
to
indicate
the
list
of
rp's
that
a
node
belongs
to,
and
an
api
id
list
is
up
to
our
way
to
indicate
the
list
of
rpgs
that
a
link
belongs
to
an
rpid
for
our
two
functions
to
otherwise
advertise
the
rpid
file
to
conduct
number
associated
with
a
pirate
house.
Three.
At
this
thing,
and
also
they
found
an
appearance,
they
said
blood
an
rp
language
at
the
nrp
prefix
state
for
srv6.
O
O
And
this
is
for
an
api
id
list,
software,
the
rp
ids,
the
tr
way-
is
associated
with
the
link
on
our
I,
and
this
is
the
format
of
the
rpid
list.
O
O
O
O
To
advertise
multiple
nrp
to
the
controller
as
this
is,
it
needs
to
be
allocated
for
an
rp
id,
and
it
does
use
this.
It
also
contains
an
rpid
which
is
identifies
the
rpid
information
corresponding
to
the
additional
next.
Please.
O
This
is
the
happy
lions
acid
inline,
a
stab
network.
Obviously
8667
defines
the
language
you
see
some
qre
for
water
to
advertise.
The
agency
state
of
each
of
its
neighbors,
another
large
associated
advertisement.
O
This
is
rpc
for
srv6,
as
I
always
see,
contributes
with
ipv6
prefix
the
world
test.
Using
the
new
pdpr,
I
thought
we
built
tlw
and
associated
with
pdpr
is
prefix.
Now
I
saw
physics
located
here.
It
was
introduced
the
draft
idr
gpis
as
research
to
advertise
as
a
reasoning,
location
and
additional
attributes
for
the
given
srv6
locator,
a
new
snl
e6000k.
O
P
O
So
we
had
this
this
car
said,
but
I
think
it
is
better
to
separate
it.
It
is
better
to
have
separate
distract
to
this.
F
Q
R
R
Please
this
page
just
shows
a
very
brief
introduction
to
the
work
in
that
net.
The
most
important
features
introduced
by
the
net
cues
is
boundary
latency
and
the
bonding
cheater
also
zero
packet
loss
and
upper
bound
on
out
of
order
packet
delivery.
R
This
document
is
try
to
give
some
the
introduction
to
our
work
about
how
to
extend
bgprs,
to
support
that
net
resource
allocation
and
set
up
explicit
routines
that
can
satisfy
the
requirement
of
the
net
next
slide.
Please.
R
R
Actually,
this
is
very
similar
to
the
bgpls
extension
for
igp
traffic
engineering,
because
that
net
bandwidth
allocated
in
each
link
could
be
different
from
non-data
flows.
So
we
defined
two
separated
attribute
in
for
that
net.
One
is
a
maximum
then,
and
reservable
bandwidth
subtle.
We
which
specify
the
maximum
amount
of
bandwidth
that
could
be
reserved
for
that
net
on
this
link,
and
this
value
should
be
smaller
than
the
value
of
maximum
reservable
link.
Bandwidth
defined
erc
of
5305.
R
And
also
there
another
attribute
is
then,
that
available
bandwidth,
subtle,
which
defines
the
available
bandwidth
that
can
be
reserved
for
the
net
flow
on
this
thing.
For
now,
which
is
the
value
of
manners,
the
the
the
net
bandwidth
that
have
already
been
allocated
for
the
existing
tenant
streams
next
slide,
please.
R
This
time
this
slide
shows
the
the
link
attribute
tlvs
we
try
to
introduce
for
enhanced
that
net.
The
the
key
point
here
is
that
for
that
now
flows,
the
the
bandwidth
is
not
enough
for
the
the
resource
information,
because
then
that
requests
the
boundary
latency.
R
So
we
introduced
a
new
attribute
called
time
resource
subtle
when
the
underlying
technology
is
a
logical,
cue,
based
scheduling
mechanism,
it
represents
a
qid
and
there
are
different
technologies
for
implementing
logical
cues,
for
example,
the
existing
queues
mechanisms
or
flexi
or
other
implementation,
and
when
the
underlying
technology
is
time,
scheduling
based
mechanisms,
it
can
represent
a
time
slot
that
could
be
allocated
for
dyna
flows
in
each
link.
R
They
introduced
the
cyclic
qe
mechanisms
which
could
be
considered
as
a
special
form
of
the
time
scheduling
whose
time
slot
is
with
equal
length,
because
there
are
two
types
of
underlying
techniques.
So
we
we
also
introduced
two
type
of
time
results.
Subtly
one
is
time
resource
for
logical
q,
subtle,
v
and
another
is
time
resource
for
time,
scheduling
subtle
in
the
time
resource
for
logical
queue,
subtle
v.
R
The
basic
idea
here
is
that
we
have
a
set
of
queues
and
each
queue
has
a
buffer
size
and
a
abandoned
volume,
and
these
two
features
is
to
guarantee
the
the
packet
going
through
the
queue
with
max
expected
maximum
carrying
delay
and
minimum
queuing
delay,
and
also
the
expected
delay
variation.
R
So
that
is
different
from
the
traditional
bandwidth
allocation
mechanisms
and
another
another
attribute
is
time,
results
for
time,
scheduling,
subtle
and
the
the
the
attributes
we
introduced
include
time,
slot
lens
temp
slot
start
time
and
time
slot
and
time,
which
means
that
we
can
allocate
a
particular
time
slot
for
the
link
to
a
particular
net
flow
next
slide.
Please.
R
And
also
for
the
node
attribute
tlv,
we
also
a
new
tlv
called
dynamite
processing,
delay
subtle
in
scope
of
done
that
the
the
delay
of
each
hub
is
divided
mainly
into
three
parts.
R
One
is
link
delay,
one
is
processing
delay
and
the
one
is
queuing
delay
considering
that
queuing
delay
could
be
guaranteed
by
some
queuing
mechanisms
and
which
is
described
with
the
time
resource
id
we
have
already
introduced,
and
this
part
will
just
shows
that
in
in
that
net
packet
processing
delay
begins
after
the
packet
goes
into
the
input
port
and
ends
up
before
the
packet
arrives.
The
output
buffer
can
expect
it
in
a
known
range,
so
the
the
value
of
this
processing
delay
could
be
the
new
attribute
for
enhancer
than
that
next
slide.
Please.
R
R
So
we
would
like
to
collect
the
comments
both
from
idr
and
ios,
our
working
group,
and
also
we
would
like
to
seek
for
further
cooperation
with
people
who
are
interested
in
this
work.
Thank
you.
Q
Q
So
redundancy
protection
is
a
generalized
protection
mechanism
that
used
in
the
context
of
the
sr
and
as
shown
in
this
figure,
that
it
replicates
the
service
packet
at
the
redundancy,
node
and
transmit
through
transmit
the
copies
of
the
packet
through
different,
multiple
different
destroyed
paths
and
it
and
the
merging
node
transmit
correct
the
first
correct
and
re-eliminate
the
redundance
packet.
Q
At
this
note
right
now,
we
have
four
job
to
introduce
this
mechanism.
The
first
one
is
the
the
first
one
introduced
the
identity,
seed
and
emerging
seed
in
the
date
plane
and
the
second
one
introduced
the
redundancy
policy
in
the
control
plane.
So
the
other
two
actually
are
the
pcep
and
bgp
extensions
to
support
the
the
redundancy
policy.
Q
And
here
is
the
background
information
about
the
redundancy
policy.
It
is
defined
as
a
variant
of
sr
policy,
with
minimum
changes
and
inherits
the
main
structure
and
the
most
of
the
attributes
from
the
s
of
the
sr
policy,
and
next
please.
I
think
we
have
more
information
here
here
that
down
the
left
side.
We,
it
is
the
information
model
of
the
history,
dentist
policy
and
in
this,
in
the
redemptive
policy
we
introduce
a
new
optional
attribute
and
the
candid
candidate
past
level
and
the
new
flag.
Q
So
on
the
on
the
right
side,
it
is
the
btp
encoding
structure
and
we
at
the
same
time,
correspondingly
we
introduce
another,
introduce
another
attribute
of
the
redundance
flag
and
and
and
and
for
the
redundancy
policy
that,
if
we,
if
the,
if
this
as
our
policy
is
with
the
redundancy
flag,
so
all
the
segments,
all
the
sudden,
all
the
seed
lists-
are
all
the
sales
in
this
candid
path
are
used
for
the
redundancy
redundancy
forwarding.
Q
It
means
that
each
list
will
carries
entire
copy
of
the
service
packets
so
and
in
so
in
this
is
in
this
case
that
there
is
no
weight
because
there's
no
load
balancing
function.
It
means
that
the
weight
of
each
list
is
not
applicable,
so
on
the
other
on
the
right
side
are
on
the
right
side,
so
there
is
no
weight
attribute
for
each
segment
list.
Q
So
here
we
defined
a
new
flag,
sub
trv
for
this,
for
the
at
the
candidate
past
level,
and
this
new,
this
new
flag,
sub
trv,
is
optional
trv
and
it
distribute
the
the
flag
of
the
of
the
candid
pass.
Q
Currently,
we
used
eight
eight
bit
to
convey
the
flag
information,
but
at
this
writing
time
that
we
only
there's
only
one
flag,
redundancy
is
defined,
and
next
please.
Q
Q
This
only
can
only
be
the
redundancy
segment
and
all
this
background
information
is
described
in
the
previous
draft,
describe
the
redundancy
protection
under
the
redundancy
policy,
so
it
when
the
redundancy
policy
is
associated
with
the
bounding
segment,
the
redundancy
segment,
and
so
this
so
the
bounding
seed
or
the
srv6
foundation
seed
and
the
endpoint
behavior
of
this
bonding
seed.
Q
Q
So
next
step
for
this
drafted,
we
would
like
to
have
more
discussion
on
the
mailing
list
and
for
the
basic
that
we
need
to
to
keep
aligned
with
the
progress
in
spring
the
progress
of
the
redundancy
policy
and
thank
you
for
the
for
listening,
and
we
would
like
to
have
more
com
to
hear
comments
and
testers.
Thank
you.
C
J
Hello,
everyone
we
can
hear
you.
This
is
sony
from
huawei.
We
did
a
pgpsr
policy
attention
for
enhancer
that
night
next
slide.
Please.
J
J
The
overall
architecture
for
datum
deterministic
networking,
which
prices
are
capable
ability
to
carry
a
specific,
unique
customer
or
multicultural
flaws
with
a
tree
extremely
low
date,
loss
rates
and
bonded
to
the
latency.
With
a
network
domain
draft
ytt.net,
enhancer.
J
J
Bonding
intensity
information
is
used
to
indicate
the
requirement
and
resource
allocation
for
each
of
the
nodes
in
the
past
to
guarantee
the
bonding
latency
transmission,
when
using
as
our
policy
to
deliver
the
candidate
that
net
pass,
the
bi
needed
to
be
absolutely
in
the
sr
policy
and
then
the
hydro
node
of
pulsator
and
writes
it
into
a
package.
The
format
of
vr
is,
as
the
finger
material
below
there
is
a
proposed
interactive,
vcc.net
enhancer
data
plan.
J
We
need
different
kinds
of
bi
to
guarantee
the
bonding
intensive
transmission.
The
our
officer
knows
our
addresses
in
the
explicit
path
indicated
by
the
segment
is
a
request.
A
different
vr
media
in
our
at
least
the
sub,
carry
to
provide
the
bonded
latest
information
for
each
node
or
addresses
in
their
path.
J
While
the
author
knows
all
adjusters
in
the
inspire
indicated
by
the
segment
list,
requests
the
same
price
with
the
funds
or
shared
brs,
some
pra,
to
provide
a
drop
bond
digital
entity
for
all
journals,
because
each
segment
list
represents
a
path.
Another
bonded
length
is
also
assorated
with
a
puzzle,
so
the
bonded
lantern
information
needs
to
be
encapsulated
in
the
segment
list.
J
Nexus
class
please,
this
is
the
plus
procedures
that
hold
the
orange
originating
nodes
under
the
receiving
node
deal
with
the
boundary
latency.
The
origin
to
the
originating
node
of
sr
policy
master
includes
the
authority,
the
boundary
lantern
in
the
gpt
internal
encounter
solution
attribute
of
the
bgp
sr
policy
for
the
bonding
latency
conducted
parts.
Oh
well,
bgp,
speaker,
sales
are
isa.
J
J
S
S
Yes,
this
work
has
been
presentated
at
iatf
101
109
meeting
until
we
get
on
a
feel
good
feedback
along
the
ietf
community.
Thank
thanks
to
everyone
for
their
use
for
the
comments
and
the
suggestions.
At
this
point,
all
that
commons
has
have
been
adjusted
here
is
update.
Since
the
last
presentation,
we
added
some
text
to
enable
to
configure
local
policy
to
reflect
updates
to
to
match
the
pgps,
and
we
add
a
test
test
on
security.
Consideration.
S
Here
we
give
a
detailed
example
to
describe
a
white
node
use
rt
to
identify
the
target.
Node
rt
is
designed
to
control
export
and
import
of
the
vpn
looks
an
arty
can
be
shared
by
multi,
multiple
nodes
in
our
example
node
a
otherwise.
The
vpn
follows
back
the
load
with
two
artists,
rt
mode
b
and
rd
ladder.
The
node
b
rt
is
used
to
identify
the
node
b
and
the
red
rt
is
used
to
export
a
loader
tool.
We
have
red
r
left
left
lens
level
level.
Reflector
such
loose
to
the
node
b.
S
S
S
All
the
call
all
unknown
comments
has
been
have
been
addressed.
Now
we
will
request
the
wg
adopter
list
list
worker
and
any
more
question
or
comments
are
where
canada,
let's
all
thank
you.
J
T
Okay,
thanks
for
arranging
this
topics,
but
I
can
now
see
the
slides
now.
T
T
Okay,
for
that
extensions,
we
define
a
new
subtitle.
We
call
the
energy
subtley
and
the
easily
tunnel
caps
attribute.
It
can
be
carried
in
this
big
handling
attribute
when
the
tunnel
type
is
data
policy,
and
this
format
is
showing
this
figure
and
we
have
the
flex
field.
None
of
the
flash
is
defined
as
for
now
and
the
result
field
is
also
reserved
for
future
use
and
the
four
octet
nrp
id,
which
is
to
identify
the
domain
specific
significant
identifier
of
the
nrp
value,
zero
and
the
f5
are
reserved
okay
next
page,
please.
T
Okay,
so
here
is
the
updated
gps
policy
encoding.
We
can
see
here
we
add
the
nrp
tle
as
a
attribute
of
the
candidate
path,
so
that
it
is
shown
in
this
encoding
structure.
T
We
think
that
is
so
that
we
can
identify
the
an
rpid
associated
with
a
specific
as
our
policy
candidate
pass
with
this
mechanism.
Okay,
next
page.
T
Okay,
so
for
the
procedures,
basically,
the
original
originating
node
of
the
data
policy
should
include
this
nrp
sub
tlc
in
the
bjp.
Tunneling
caps
attribute
of
the
sub
policy
to
specify
the
associated
energy
and
the
setting
of
other
fields
are
not
changed.
T
T
C
T
Six
here
we
are
some
operational
considerations,
although
we
think
this
proposed
mechanism
allows
to.
I
then
associated
the
different
kennedy
path
in
one
as
a
policy
with
different
nrps,
but
in
normal
scenarios
it
is
considered
that
association
between
the
assad
policy
and
nrp
is
consistent.
T
So
for
the
next
steps,
I
think
this
mechanism
is
straightforward
and
the
document
is
short.
I
would
like
to
suggest
people
to
give
it
a
read
and
send
comments
and
feedbacks
to
us
out
to
list,
and
we
would
also
think
this
draft
is
has
been
stable.
So
maybe
we
consider
double
group
adoption.