►
From YouTube: IETF115-IDR-20221107-1300
Description
IDR meeting session at IETF115
2022/11/07 1300
https://datatracker.ietf.org/meeting/115/proceedings/
A
A
F
Unless
I
have
foreign,
okay,
there's
a
note.
Well,
if
you've
not
read
your
note
well,
please
take
a
moment
to
read
your
note
well
and
determine
that
once
you've
been
here,
you're
green
to
be
follow,
ITF
file,
policy
processes
and
policies,
we
recommend
masks
unless
you're
speaking
at
the
mic
next
slide.
F
F
F
F
This
is
our
current
status.
We've
adopted
draft
ITF,
ID
or
TS
flow
spec
srv6
policy,
we'll
probably
go
right
into
working
group
last
call
as
an
informational
We've
adopted
draft
ITF,
bgp
entropy
label
kudos
to
the
authors
for
a
really
good
ITF
collaboration.
We've
adopted
spaghetti
deprecate,
but
we
then
found
out
thanks
to
Bruno
that
there
was
some
of
that
information
in
an
RFC.
So
we're
probably
going
to
abandon
that.
Thank
you
to
those
who
are
helping
us
with
that.
F
We
adopted
two
things
since
which
is
Haas
the
interoperability
draft
for
car
CT,
which
is
Draft
House,
IDR
diffract
and
we've
tentatively
adopted
draft
Dunbar,
but
there's
a
canned
off
on
the
same
topic,
so
that's
sort
of
in
the
whole
position
and
we've
not
addressed
Daft
Wang
IDR,
VPN
prefix.
You
can
ask
me
questions
in
the
back
about
all
of
this.
F
Our
major
work
items
I'm,
giving
you
a
status
because
we
have
a
little
latitude
this
time
we
the
DC
drafts
for
BGR
configuration
in
case
you
missed
the
message
we
sent
those
to
drop
because
we
didn't
get
enough
interest
in
the
working
group.
We
encourage
the
authors
to
go
to
ISE.
We
need
any
feedback
if
we
should
pick
up
the
non-data
center
considerations,
if
we
don't
hear
feedback,
we'll
go
on
to
other
major
work,
float,
bgp
flow,
spec,
I
really
need.
And
again,
this
is
the
call
from
the
chairs.
F
I
really
need
to
talk
to
the
flow
spec,
V1
path
redirect
and
interface
set
authors,
as
I
haven't
heard
from
you,
and
we
either
need
to
go
on
or
drop
those
and
most
of
the
drafts
for
flow
spec,
as
we
see
coming
up
in
the
working
group,
should
go
to
flow
spec
V2.
We
are
starting
to
get
implementations
thanks
to
Gunter
for
some
error
reports,
color
CT,
we're
going
to
look
at
draft
Wing,
ID
or
CPR
and
I
have
a
little
pre-hint
that
they're
going
to
be
asking
for
adoption.
F
So
we'll
look
at
that
next
top
is
our
next
topic.
We
would
appreciate
any
comments,
thoughts
and
other
things.
Another
thing
I
need
feedback
for
and
again
catch
me
in
the
hall
or
at
the
back
I'm
about
ready
to
engage
in
the
cleanup
drafts
that
are
IDR
drafts
that
are
older
than
10
years,
just
to
sort
of
clean
out
our
back
too
I
think
that's
it
Jeff.
D
D
So
this
is
a
bgpls
draft
and
it
introduces
change
extensions
for
advertisement
of
tea
policy
policies,
so
these
could
be
rsvpt
tunnels,
segment,
routing
policies
or
mprs
cross
connects
in
that
sense.
This
is
different
from
sourcing
information
from
igp
into
bgpls,
which
was
the
you
know
in
the
base
pack.
D
So
a
quick,
high
level
status
update.
While
this
document
has
been
in
idea
working
group,
the
base
Sr
policy
architecture
has
was
published
as
RFC
9256
The
Sibling
draft.
We
could
call
it
that
way.
The
bgpsr
policy
is
has
been
sent
to
ISD
for
publication.
That
draft
defines
the
controller
to
the
router.
You
know
provisioning
of
Sr
policies,
while
this
draft
does
the
reporting
in
the
other
direction
over
the
past
few
years,
the
draft
has
been
getting
updates.
D
So,
since
the
last
ITF
we
had
a
bunch
of
updates
which
were
posted,
I
I
believe
around
August,
and
these
were
all
based
on.
You
know:
implementation
feedback,
so
the
good
part
is
there,
are
implementations
already
done
or
ongoing
for
this
draft?
One
of
the
key
things
was
that
we
use
separate
nlri
types
for
each
type
of
policy,
so
a
separate
NRI
for
rsvpt
tunnel
for
Sr
policy,
and
you
know
so
on
any
other
things
which
we
may
introduce
in
the
future.
D
So,
where
is
where
are
we
at?
So
we
are
still
getting
some
feedback
from
implementation,
and
more
closer
reviews
are
happening.
So
that's
good.
Thank
you.
We
have
some
updates
from
in
the
Ayana
section,
based
on
some
comments
and
some
more
expecting
to
get
during
this
week.
So
right
after
ITF,
we
can
expect
perhaps
one
more
update.
D
So
this
is
a
proposal
from
the
authors
and
to
the
working
group.
I
would
also
send
it
out
over
the
email,
but,
given
that
we
have
some
at
least
a
few
implementations
for
the
SR
policy,
we
could
look
at.
Perhaps
splitting
the
draft
a
working
group
draft
into
two
parts
so
that
one
of
them
may
progress
to
working
group
last
call
and
publication,
so
any
inputs
or
feedback
would
be
very
much
appreciated.
A
It's
certainly
possible
to
split
it.
The
work
would
remain
adopted.
I
believe
what
you'd
probably
want
to
do
is
prepare
a
version
of
the
split
document,
so
we
can
see
what
it
looks
like
the
usual
challenge
we
have
for
those
sorts
of
things
is
making
sure
that
each
document
is
whole
in
on
its
own
and
make
sure
that
it
is
easy
to
read.
A
So
I'm
Jeff
house
and
I'm
presenting
on
behalf
of
the
HP
Yang
battle
authors
next
slide,
please
so
status.
We
have
done
a
lot
of
work
in
the
model
in
terms
of
updating
the
Transport,
Security
and
I
have
worked
with
the
TCP
Yang
model.
Authors
specifically
on
how
tcpao
is
supposed
to
work
and
also
tcpmd5
that
did
result
in
some
work
inside
the
tcpm
working
group
to
fix
some
issues
that
they
had
in
their
model
and
we're.
A
You
know
one
of
the
first
users
of
the
fixes
so
as
a
side
effect,
we've
removed
some
of
the
stuff
from
our
end
of
the
model
and
moved
it
into
theirs,
and
we've
updated
the
appendix
to
take
care
of
that.
We've
done
cleanup
on
a
number
of
things
relating
to
unions.
You
know
courtesy
of
some
of
the
netmod
rules
in
Yang.
The
order
does
actually
matter
in
terms
of
what
catches
the
possible
options
within
the
Union.
A
We've
also
done
some
additional
work
inside
the
policy
module
specifically
on
you,
know,
matching
and
address
families
and
neighbors,
and
we've
added
no
additional
examples
for
matching
desktops
and
communities
next
slide.
Please
so
Mahesh
is
still
running
the
GitHub
that
we're
doing
all
of
our
stuff.
Out
of
you
know,
please
take
a
look
at
it
in
case
you
want
to
you,
know,
open
up
issues
or
contribute.
We
are
tracking
things
via
issues.
You
know
for
our
lingering
work
items
we
have
cleaned
up
some
of
the
regular
expression
type
stuff.
A
A
In
Richmond,
six
around
the
corner
here
on
the
specific
topic,
we'll
discuss
possible
options
there
and
if
we're
lucky,
we
come
to
some
sort
of
easy
consensus
and
perhaps
move
this
item
forward
for
next
itif,
which
will
close
out
the
major
pieces
of
missing
work,
the
s
override
and
replace,
as
we've
made
some
choices
there.
We
invite
the
working
group
to
please
review
this,
because
this
is
a
non-standard
feature
outside
of
the
ASO
override
use
case.
A
You
know
for
vpns
and
extended
communities
continue
to
be
one
of
the
more
challenging
pieces
of
modeling,
both
in
terms
of
how
to
actually
model
route
targets,
but
also
you
know
the
fact
that
ietf
is
adding
new,
extended
communities
on
a
regular
basis
and
making
sure
we
can
maintain
this
without
having
to
issue
a
new
RFC
as
real
single
time.
We
do
it.
You
know
those
of
you
are
following
Yang
modeling
are
invited
to
give
this
very
deep
scrutiny.
A
This
is
a
type
of
thing
that
the
rest
ietf
does
not
have
as
a
general
problem
next
slide,
please
so
we're
mostly
there.
We
are
hoping
that
once
we
solve
the
regular
expression
issue
that
we
have
dealt
with
everything
there's
a
tiny
bit
of
cleanup
work
left
to
be
done.
We're
starting
to
see,
know
some
feedback.
You
know
coming
in
from
the
field.
A
A
We
invite
deep
scrutiny,
and
in
particular,
since
this
module
will
be
the
basis
for
how
a
number
of
other
VPN
family
type
things
like
modules
that
come
out
of
best
tie
into
it's
also
important,
for
you
know,
people
working
on
the
best
Yang
modules
to
pay
attention
as
well
and
I
believe
that
is
all
we
have
on
this
slide.
Is
there
any
questions.
C
A
A
A
So
what's
the
motivation
we
have
to
talk
about
this
topic,
so
it's
worth
never
taking
a
brief
reminder
that
bgp4
came
into
being
as
the
first.
You
know:
inner
domain
protocol
for
carrying
class
listener
domain,
classless,
Internet
domain
routing
and
as
a
side
effect,
there's
a
lot
of
procedure.
That's
sprinkled
across
4271
and
earlier
1771
dealing
with
you
know,
topics
that
are
less
interesting
these
days
than
they
used
to
be
specifically
aggregation.
A
And
you
know
the
algorithm
is,
you
know
fairly
straightforward?
You
know
the
one
that
pretty
much
everybody
on
the
planet
implements
these
days
is
for
all
your
contributors
find
the
longest
common
set
of
leading
sequences.
That's
the
sequence.
Everybody
shares
take
everything
else,
throw
it
into
a
set
and
de-duplicate
the
as
in
the
set,
and
once
you've
actually
done
that
generate
the
minimum
number
of
DGP
segments
to
encode.
A
The
thing
on
the
wire
4271
also
talks
about
the
atomic
aggregate
attribute,
which
had
a
lot
of
interesting
controversy
as
we
were
specifying
4271
and
you
know,
cleaning
up
1771
effectively.
What
it's
used
for
in
4271
is,
if
you
set
Atomic
aggregate
you're
allowed
to
throw
away
the
ASF
portion
of
it
aggregate
if
you
think
it's
safe,
you
know
the
original
intent
of
atomic
aggregate
was
don't
make
this
route
more
specific
or
don't
you
know
de-aggregate
it.
No
implementation
on
the
planet
does
this
by
default.
These
days,
it's
usually
done
by
other
procedures.
A
A
If
as20
sends
its
route
to
10
and
10
was
to
use
that
to
form
an
aggregate,
then
it
would
just
simply
since
it's
the
longest
common
path.
Well,
it
just
has
a
s
path
of
20
in
here.
So
this
is
the
case
where
aggregation
can
happen
if
there's
no
sets
present.
So
what
might
actually
happen
next
slide
if
you
re-advertise
this
back
around
the
corner?
Well,
so
imagine
that
as20
really
isn't
using
its
full
set
of
address
space
and
has
holes
on
things.
Maybe
it's
using
one,
slash
24
as
an
example.
A
If
it
accepts
the
less
specific
route
and
doesn't
have
something
internally
to
catch
for
the
traffic
for
the
network
that
it
leaves,
it
owns
the
slash
16..
This
can
be
a
case
where
the
you
know,
traffic
forwards
back
and
forth
to
each
other
now.
Clearly,
this
doesn't
happen
in
practice
these
days,
but
remember,
4271
and
bgp
in
general,
came
into
being
before
some
of
these
things
were
absolutely
clear
procedure
wise
now
for
the
most
part
providers.
A
This
becomes
a
little
more
interesting
if
you
actually
have
the
as
present
as
part
of
the
aggregation
and
send
it
back
towards
the
contributors.
Well,
the
contributors
would
have
simply
not
consume
the
less
specific
route
and
as
a
side
effect,
this
type
of
problem
should
not
happen.
So
that's
that's.
The
motivation
for
things
like
sets,
however,
sets
caused
us
interesting
problems
next
slide.
Please.
A
Again,
current
practices:
how
do
we
avoid
this
actually
being
a
problem?
Well,
filtering
your
own
address
space.
You
know
it's
common
practice
that
if
you
own
a
set
of
prefixes
you're,
not
going
to
accept
more
specifics
for
your
own
networks
from
the
outside
world,
you
know
it
can
be
lead
to
you
know,
route
hijacks
as
an
example,
the
trick
is
while
policy
is
very
easy
for
that
not
consuming
less
specific
routes
from
the
outside
world
is
very
difficult
to
do
in
bgp
policy.
A
So
the
practice
everybody
has
is,
if
you
don't
form,
you
know
an
aggregate
or
something
else
internally
to
catch
all
the
traffic
you'll
do
something
like
know
about
the
traffic
internally
aggregations
normally
how
this
operates.
But
you
know
there
are
other
techniques
and
if
you
do
these
things,
you
know
the
actual
forwarding
Loops
are
covered
next
slide.
Please
now
the
question
is:
why
do
we
actually
even
care
about
any
of
this?
You
know
why
do
we
care
about
assets?
Well,
B2B
security
features
that
pushed
us
down
the
path
where
this
is
now
important
route.
A
Origin
validation
needs
a
deterministic
origin
as
for
Route
origin,
authorization
records
and
the
problem
with,
as
said,
is
it's
ambiguous
who
the
actual
origin
is
in
those
circumstances?
So
it's
recommended
64.72,
don't
do
this.
You
know
we
want
something
to
be.
You
know
canonical
for
Route
origin
validation.
A
It
also
makes
things
like
policy
very
challenging,
nobody's
policy
engine
on
the
planet
right
now
that
I'm
aware
of
actually
can
match
on
sex-
and
this
makes
things
very
annoying
and
Warren's
over
here
shaking
his
head
is
like
this
makes
my
life
difficult.
Let's
not
do
this,
so
this
is
I,
don't
like
it
rather
than
the
security
feature
in
the
last
case.
Is
that
for
bgp
SEC
purposes,
bgb
SEC
needs
to
have
sequences
to
do
its
signatures
over.
A
So
that's
a
further
motivation,
One
Step
stronger
than
as
sets
you
know,
conf,
there's
phb
SEC
procedures
for
confederations
as
well.
Now
the
useful
thing
is
sets
are
not
common.
You
know
a
few
years
ago
when
this
document
was
richly
authored.
There
was
300
of
them
floating
around
the
internet,
they're
significantly
fewer
largely
as
motivated
by
bgp's,
not
PHP
SEC,
but
rpk
origin
validation
is
just
simply
causing
these
things
to
go
out
of
existence.
Your
stuff
won't
validate
with
them.
That
said,
aggregation,
Still,
Remains,
quite
common.
A
A
So
what
are
we
asking
to
be
changed
here?
Number
one.
You
should
do
Treatise
withdrawal,
basically,
if
you're
going
to
accept
them
at
all,
don't
propagate
them,
probably
don't
even
use
them.
This
is
a
change
from
the
must
and
the
prior
version
of
the
document,
simply
because
there
are
going
to
be
circumstances
where
people
do
need
to
do
this
and
we
can't
break
all
the
implementations.
We've
been
shipping
for
25
years.
A
That
said,
you
should
not
create
sets
when
you
do
that-
and
this
is
where
we
need
most
of
the
normative
text.
Changes
versus
4271
there's
been
procedure
for
years,
called
brief
aggregation
where
you
simply
throw
the
set
away
and
set
the
atomic
aggregate.
Brief
aggregation
was
not
well
described
inside
the
core,
Beach
brfc.
This
document
tries
to
actually
clarify
you
know
what
actual
practice
is
at
the
moment,
but,
more
importantly,
it
actually
recommends
that.
That's
not
good
enough,
because
brief
aggregation
simply
truncates
the
sets.
A
You
may
still
end
up
with
a
non-deterministic
originas
in
some
circumstances,
so
the
recommendation
this
document
that
requires
deep
scrutiny
from
the
working
group
is,
is
it
okay
to
Simply,
make
the
truncation
at
typically
the
point
of
aggregation?
That's
probably
going
to
work
out.
Fine
it'll,
give
you
a
consistent
origin,
as
for
you
know,
bgp
security
purposes
and
yes,
we're
just
going
to
keep
putting
Atomic
aggregate
at
it.
Next
slide.
A
Do
we
actually
care
about
Confederation
assets?
Well,
origin
validation,
as
I
mentioned,
does
not
care
about
it.
Bgp
set
does,
but
even
B2B
set,
you
know,
gives
you
know
some
discussion
in
its
security
section
that
you're
going
to
throw
away
all
the
signatures
done
on
beach,
be
SEC
confed
segments
outside
the
Confederation
anyway,
so
it
depends
on
your
zone
of
trust,
so
this
becomes
less
of
a
you
know.
Critical
thing
and
more
is
a
good
idea.
You
know
as
part
of
09
I
thought.
A
Maybe
we
can
probably
get
rid
of
Confederation
procedures
and
true
Ram
reminded
me
after
publication.
Well,
B2B
SEC
really
does
strongly
recommend
this.
So
we're
going
to
return
the
confed
sets
as
a
should
not
generate,
but
again
it's
less
critical
than
you
know
the
asset
for
Global
Internet
purposes,
X
slide.
A
A
It's
like
hey
guys,
it's
clear
that
you
haven't
been
dealing
with
interop
labs
for
the
last
20
years,
if
we
just
simply
throw
this
text
away
without
having
clean
procedure
to
do
so,
we're
going
to
end
up
with
our
conformance
testers
filing
a
bunch
of
bugs
with
us.
So
we
do
need
to
take
some
care
here,
so
we
will
need
some
deep
scrutiny
on
this.
But,
more
importantly,
what
we
need
to
do
is
get
vendors
to
start
implementing
the
new
aggregation
procedure
for
as
paths
to
help
you
know,
origin
validation
be
more
stable.
H
C
A
I
Job
Snyder's
fastly
a
number
of
years
ago,
operators
managed
to
get
rid
of
private
asns
in
the
default
Free
Zone
by
popularizing
certain
filters
that
operators
would
copy
paste
into
their
devices,
and
the
purpose
of
this
exercise
was
to
to
promote
some
attribution
capabilities
and
there's
an
analogy
to
the
current
situation,
where
some
might
argue
like
hey.
We
see
these
low
hundreds
of
routes
in
the
default
3
Zone,
and
we
we
cannot
get
rid
of
it.
It
will
never
happen
and
I
went
back
to
differ.
I
I
It's
it's
not
trivial,
on
on
platforms
commonly
deployed
except
open,
bgpd
and
I
want
to
encourage
HP
implementers
to
make
a
simple
button
to
just
reject
all
routes
that
have
as
sets
in
them
and
if
those
buttons
become
available,
operators
will
start
using
them
and
we
will
prune
as
set
routes
from
the
default
free
zone.
So
the
to-do
list
should
be
expanded
by
another
item.
Please
make
a
knob
to
make
it
easy
to
reject
routes
that
contain
as
sets,
and
that
will
actually
help
finalize
this.
This
project.
J
Hi
I've
already
done
a
future
way.
Technologies
I
like
this
work,
I
I
was
you
know,
happy
that
you're
deprecating,
asats
and
as
confed
sets
and
the
document
says,
you're
deprecating
It
also
says
you're
obsoleting,
but
in
reality
you're
not
right,
you're.
Just
really
saying
really
really
really
don't
use
these.
J
In
fact,
you're
actually
saying
you
should
not
be
generated,
which
means
that
people
can
still
send
them
and
people
who
receive
them
can
still
receive
them,
because
you're
saying
you
should
treat
us
withdrawal
whatever
you
said
there.
In
other
words,
we
may
see
these
forever
and
I.
Understand
that
you
know
there's
some
backwards,
compatibility
issues
and
things
like
that.
What
I
would
like
you
to
do
is
to
clarify
the
language
a
little
bit
I
mean
if
we're
obsoleting,
we
should
obsolete.
J
A
Really
right
and
a
big
portion
of
the
reason
I
got
involved
in
this
draft
is
the
initial
proposal
is
outright
apps
late.
You
don't
want
people
to
have
their
peering
sessions
dropped
because
they
receive
one
of
these
things
coming
in.
So
we
have
to
deal
with
the
fact
that
this
is
bgp.
We
have
stacks
that
they'll
have
implementations
have
been
around
for
20
years.
You
know
somebody's
got
you
know.
Ancient
protein
box
lying
around
on
their
Network
we'd
want
them
to
knock
over
okay,
no
further
questions
next
present.
G
A
K
Thank
you
so
I'm
just
making
it
very
short
presentation
on
this
next
slide.
Please
next
slide
okay,
so
this
is
actually
a
special
special
scenario
which
we're
going
to
be
covered
in
the
can
Computing
aware
networking
buff,
which
is
happening
right
after
IDR
I
hope
people
can
go
there.
If
you
have
questions
and
comments.
So
it's
really
about
you
know
small
domain
like
in
3gpp.
K
They
call
it
local
network,
local
Data
Network,
where
the
service
instances
are
extensioned,
multiple
Services,
multiple
instances
so
for
one
service,
so
you
could
have
one
address,
have
multiple
instance
created
and
is
for
the
edge
router,
the
e-quest
router
be
able
to
propagate
the
properties
of
attached
site,
for
example,
at
one
particular
site.
You
may
have
some
kind
of
we
call
it
a
site
index
side
capacity
index.
K
K
K
So
here
just
an
example
like
pgp,
you
have
many
attributes,
many
policies,
the
different
priorities,
and
here
we
got
the
extra
Services
extra
service
metadata
service,
metadata
value.
How
do
we
insert
that
into
a
chain
of
decision
point
where
to
insert
it
so
that
you
can
integrate
with
the
other
attributes
to
create
the
best
paths?
K
Next
slide,
please.
So
the
main
purpose
of
this
presentation
is
really
want
to
introduce
a
different
have
a
different
meaning
of
next
heart.
As
our
idea,
chair
has
presented
that
there
are
many
drafts,
the
different
attributes
of
next
hub-
and
this
is
a
special
circumstance,
because
this
next
hub,
like
for
example,
capacity,
doesn't
really
represent
the
next
hop.
The
router's
capacity
is
really
represent
the
attached
side
capacity
and
also
those
are
not
aggregating
on
forwarding
the
NRI
received
from
other
routers.
This
is
really
directly
attached
sites.
K
It's
more
like
a
exit
points,
egress
router
to
the
devices
in
the
igbtp
domain,
so
that
this
particular
next
hub
can
be
the
next
hub
for
other
attributes
as
well
like
other
routes
as
well
in
the
traditional
bgp
domain
that
you
have
like
this
next
router
next
hub.
Have
some
issues
will
impact
every
route
which
has
this
notes
declared
as
the
next
half,
but
for
this
circumstance
this
attributes
only
impact
the
service
instances
directly
attached.
K
So
for
this
anycast
for
this
kind
of
special
environment,
we
need
to
have
a
different
terms,
so
make
it
easier.
In
idea
of
discussing
the
future,
say
you
have
next
hub
Transit,
which
is
like
asbr
for
the
other
domains,
and
this
particular
one
is
really
the
ipgp
exit
point.
So
I
want
to
differentiate
that
page.
Please
so
here
in
this
draft,
we're
proposing
a
new
past
attribute
to
represent
the
service
metadata.
K
This
particular
past
attribute
can
impact
multiple
MRIs.
This
has
details
is
described
in
the
in
the
draft.
If
you
have
any
comments
or
any
suggestions,
please
talk
to
me
at
the
hallway
or
on
the
mailing
list.
Next
page,
this
is
just
rehab
of
some
of
the
sub
povs
can
be
carried
by
this
past
attribute
next
page
please.
K
So
today's
presentation
is
really
soliciting
more
comments
to
the
draft
and
also
asking
the
IDR
the
the
community.
Can
we
create
a
different
names
for
this
particular
next
hub,
so
make
it
easier
for
discussion
and
for
defining
for
the
future
extensions
we
want
to
have
like
next
hub
transit
for
this
particular
case,
this
next
hub
at
bgp
Exit
point.
Thank
you.
H
Hey
ceiling
of
Cisco,
I
I
think
this
attribute
doesn't
affect
the
packing
any
differently
from
any
other
attribute
at
a
high
level.
I,
don't
see
why
we
need
to
rename
the
next
top
just
oh
just
to
create,
create
or
come
up
with
something
different
and
the
next
top
is
a
required
attribute,
so
you're
it.
It
seems
much
more
invasive
than
it
needs
to
be.
Okay,.
K
H
H
Right
without
any,
without
saying
that
I'm
supporting
this,
you
could
just
associate
this
different
Behavior.
With
this
new
attribute
you
have,
rather
than
trying
to
define
the
new
Next
Top
type,
that's
what
I'm
saying
I
mean
it
would
be.
You
know
it
would
be
like
I'm
saying
it
would.
You
know
next
top
is
required.
You're
you're,
saying:
okay,
it's
required,
but
you
can
have
this
type
or
this
type,
it's
more.
It's
a
bigger
change
to
bgp,
okay,.
K
K
L
B
B
B
N
M
M
O
Okay,
I
will
present
on
behalf
of
my
colleague,
okay.
This
is
about
the
motivation
problem
statement
because
for
different
vaping
routes.
If
there
are
different
types
of
policies
available
in
the
network
to
different
PES,
the
webinars
may
need
to
choose
the
next
hub
and
the
as
a
policy
according
to
the
igb
metric
out
as
a
policy,
and
this
figure
just
gives
the
example.
P
B
O
There
is
one
as
a
policy
a
policy
one
and
I
have
policy
two,
both
as
a
policies
satisfy
the
delay
and
bandwidth
constraints,
and
they
are
candidate
for
the
to
be
used
for
this
weapon
route
and,
according
to
ig
metric,
the
there
are
kind
of
different
RGB
metric
to
reach
the
different
Pino's
by
following
this
as
a
policies,
for
example,
for
the
first
one,
the
iso
policy,
one,
the
pass
from
P1
through
P1
to
P3.
The
cost
is
of
the
igp
20,
wherefore
the
second.
O
As
a
policy,
the
igp
metric
for
the
actual
pass
will
be
120..
So
in
this
case
a
P1
would
prefer
to
choose
the
next
hub
according
to
the
I3
metric
and
use
the
asset
policy,
one
for
the
package
for
warning.
In
this
case,
and
as
our
the
network
controller,
we
need
to
deliver
the
igp
metric
for
of
the
SI
policies
when
it
advertised
as
a
policy
to
the
Ingress
node.
Okay,
let's
click
please
so
here
is
the
proposed
extension.
O
O
Okay,
here
is
the
format
of
the
Matrix
of
toe
and
the
type
is
to
be
defined
and
allocated
by
Diana.
The
lens
of
this
tlv
is
a
six
octite
there's
one
flag
field,
but
none
of
them
are
defined
in
this
version
for
the
metric
types
there's
one
octet
field
to
identify
the
type
of
the
metric
used
for
this
metric
sub
goe
and
on
the
right
side.
We
list
several
code
points
for
the
metric
types,
including
the
RGB
metric,
the
minimum
minimum
unidirectional
link
delay
and
the
T
metric.
O
O
O
O
P
D
O
Yeah,
actually
here,
the
metric
of
the
path
is
to
follow
the
ultrometric
of
the
computed
path.
So
it
is
possible
that
for
different
segment
lists,
the
measure
can
be
different.
So
that's
why
we
have
proposed
to
have
a
different,
a
separate
metric
for
separate
segment
list,
and
what
can
it
pass?
It
can
choose
the
maximum
value
of
the
metric
of
the
segment
list.
D
O
D
P
O
Yeah
in
the
use
case,
there's
just
maybe
just
one
segment
list
in
the
candid
past,
but
when
you
have
multiple
assignment
lists,
it
is
probably
you
ingressional
may
need
to
know
all
these
metrics
so
that
it
can
get
the
actual
metric
for
the
Kenny
pass.
And
maybe
that
is
you,
give
more
information
to
the
Ingress
to
make
the
decision.
A
O
Actually
not
yet,
but
actually
we
we
see
that
metric
information
have
been
distributed
from
the
devices
to
the
controller
via
bgprs
in
the
the
draft
Academy
presented
in
the
beginning.
So
we
think
for
asset
policy,
this
distribution
from
controller
to
the
a
node
that
this
information
will
be
also
needed.
Yeah.
L
A
Q
B
Q
B
B
A
G
Q
So
the
in
this
design,
the
4p
routers
exchange
ipv4
reachability,
transparently
tunneled
over
an
ipv4
core,
using
multi-portical
bgp
using
bgp
Next
Top
Field,
to
convey
the
action
usage
address
of
the
4p
router
so
that
they
dynamically
established
tunnels.
The
npv6
signal
of
mpls
LSP
can
be
utilized
without
explicit
tunnel
configuration.
So
basically,
this
is
signaling
the
top
most
legal
label
for
that
for
the
loop
effect
label,
binding
four
PE
uses
RC
8950
for
for
the
six
six
or
32
byte.
Q
Q
So
this
diagram
here
depicts
a
depicts
6pe
RFC
4798,
so
it
so
here
what
happens?
Is
you
have
the
transport
labels
first
signaled
from
the
Ingress
6pd
router
to
the
US
6p
router,
and
this
is
just
a
topmost
label:
transport
connect
label
binding
to
the
uspe
and
then
the
second,
the
service
label
bottom
stack
label,
bgplus
safety,
four
for
the
label,
binding
for
all
IPv6
prefixes
tunnel
over
an
ipv4
LSP
next
slide.
Q
So
so
now,
with
six
we're
now
with
four
PE
we're
connecting
ipv
for
Ireland
over
IPv6
mpls
core,
so
here
what
we're
doing
we're.
Similarly,
we
the
4p
routers,
the
USP
router
to
the
ESP
router,
we're
signaling,
a
an
LSP
to
the
e-respeed
router.
We
need
back
connect
label
binding
for
the
transport
label
and
then
the
service
label
bottom
of
the
stack
label,
we're
we're
using
bgplus.
Thank
you
for
legal.
Creating
a
label
bind
for
all
the
i324
prefixes
tunneled
over
the
ipd6
LSP
next
slide.
Q
Thanks
so
this,
this
draft
is
extensible
to
Sr
and
pis,
so
with
segment
routing.
What
happens
is
the
egress
P
signals,
the
Ingress
Community
with
a
VPN
color,
and
that
VPN
caller
is
mapped
to
an
Sr
policy,
Sr
policy,
color
of
to
color
to
intent,
mapping
and
then
the
patches
and
instantiated
to
the
prefix
that
you
said
of
the
e
recipe
and
and
then
at
the
at
the
service
layer,
bgplu
Sac,
E4,
the
all
all
the
V4
prefixes
are
labeled
and
titled
across
the
IPv6
LSP
next
slide.
Q
This
wraps
is
also
extensible
to
srv6
and
with
with
Sr
V6
similar
to
the
srmpls,
we
have
the
caller
to
intent.
Mapping
that
happens
where
the
ESP
signals
color
for
Destiny
per
destination,
color
or
or
per
flow
can
also
is
also
supported
from
the
USB
in
USP
color,
1010
mapping,
and
then
the
LSP
is
built
to
the
egress
notes.
A
Q
Q
A
B
R
R
R
R
R
R
So
the
second
potential
risk
is
the
black
hole
so
similar
with
the
risk
one.
If
some
misconfiguration
happen
that
will
cause
the
traffic
is
directed
such
as
from
the
65
104
to
as65,
500
and
the
it
has
a
6500
may
not
be
have
a
rotate
to
the
destination
server,
then
the
traffic
will
be
discussed
that
will
result
in
a
traffic
black
hole.
R
R
In
the
the
last
potential
risk
here
is
operation
and
a
maintenance
risk,
so
you
know
the
traffic
redirection
may
cause
inconsistency
between
the
control
plan
and
the
forwarding
plan.
So
if
the
networker
operation
element
in
control
system
doesn't
guide
the
traffic
redirection
information
in
the
network,
some
predictable
risk
will
occur
during
the
traffic
optimization.
R
R
Some
object,
operation
rules
to
avoid
those
risks,
maybe
it's
necessary
to
exploit
some
new
Technical
Solutions,
such
as
redirection,
configuration
verification
tools
or
some
protocol
extension
to
sync
up
the
forwarding,
plane
and
control
it
or
some
past
virtualization
tools
to
reduce
those
risk
mentioned
in
this
draft.
This
draft
cannot
give
some
Direct
Solutions
but
one
hand
the
redirection.
R
A
N
H
Just
had
one
comment
here
and
I've
talked
to
this:
some
people
about
this.
It
seems
almost
to
imply-
and
it's
like
the
big
elephant
in
the
room
with
flow
spec
that
it's
being
used
not
for
it's
an
original
purpose,
but
now
it's
being
used
as
sort
of
like
an
open,
Flow
and
people
are
using
it
for
their
routing
mechanism
instead
and
I.
Think
that
you
know
needs
to
kind
of
come
out.
H
If
that's
the
intention-
and
you
know-
and
this
this
does
a
good
by
addressing
the
redirection
as
if
it
were,
maybe
I've
just
missed
it.
But
it's.
It
appears
to
me
that
this
is
this
is
happening
and
I'm
wondering
to
what
extent
it
has
and
how
much
how
many
people
are,
if
anybody,
how
many
people
are
deploying
controllers
that
use
this
as
a
open,
Flow
type
protocol.
B
A
O
O
We
know
that
PHP
flow
spec
provides
the
mechanism
to
distribute
the
flow
specifications
and
the
flow
forwarding
actions
to
be
performed
to
the
match,
the
traffic
and,
in
the
context
of
itm
network
slicing,
the
network
slice
traffic
needs
to
be
steered
into
an
NRP
to
meet
the
connectivity
and
also
the
performance
requirements
as
defined
in
the
item.
Nether
slice
framework
draft
NRP
is
a
collection
of
network
resources
in
the
underlying
Network
and
in
the
data
package
an
RP
can
be
identified
using
either
resource
Awards
srcs
or
the
dedicated
nrpid
in
the
packet.
O
O
Firstly,
we're
talking
about
the
matching
rules
for
the
Network
slash
traffic.
Basically,
all
the
existing
flow
spec
components
can
be
reused
to
match
the
network
style
service
traffic.
These
components
are
defined
in
the
RFC
8955
and
8956,
and
in
some
other
scenarios
the
packet
may
already
be
encapsulated
with
an
rpid
and-
and
in
this
case
the
Ingress
node
may
need
a
new
flow
spec
component
to
match.
The
nrpid
in
the
packet
and
format
of
the
NRP
ID
component
is
shown
in
this
figure.
O
This
component
encoding
aligns
with
the
specification
in
flow
spec
version
2.
and
in
the
flash
field
one
flag
is
defined
in
the
current
version,
the
G
flat,
which
is
used
to
indicate
whether
the
NRP
ID
is
a
globally
unique
or
is
it
like
a
domain
significant
and
for
octite?
Identifier
of
the
NRP
is
also
carrying
this
component.
O
O
And
regarding
the
necro
slice
traffic
steering
actions,
basically,
the
traffic
of
the
network
slice
can
be
steered
into
an
RP
and
then
be
forwarded
using
two
approaches.
The
first
one
is:
we
can
use
a
shortage
path
within
the
NRP
and
in
the
second
approach
is
we
can
use
a
traffic
engineered
or
te
pass
associated
with
NRP
and
in
for
the
first
case,
if
we
want
to
steer
the
traffic
to
a
shortest
pass
or
call
it
be
pass
within
NRP,
we
can
use
a
two
approaches.
O
Okay,
next
slide,
please
for
the
second
case,
if
you
want
to
steer
the
traffic
to
NRP
specific
te
pass,
we
can
use
the
mechanism
to
steal
the
traffic
to
as
a
policy
which
is
associated
with
NRP,
and
similarly,
we
have
two
approaches
to
associate
Isa
policy
with
an
RP.
Either
we
can
use
NFP
specific
resource,
aware
segments
to
build
the
asset
policies
list
or
we
can
associate
as
a
policy
with
a
database
NRP
ID
and
impose
of
the
above
cases.
I'd
have
never
slice.
O
O
N
N
So
here
we
have
a
bonding,
which
is
that
we
have
a
bunding
seed,
B
seed
associated
with
a
list
of
segments
which
is
S1
and
S2.
This
S1
S2
defines
a
green
per
segment
so
when
pgp
sends
binding
to
node
n,
which
is
a
piece
it
with
segment
list,
S1
S2
in
normal
operation,
with
node
n,
receives
a
package
responding
seat.
So
node
n
will
replace
this
panel
sheet
with
the
list
of
seats
which
is
S1
and
S2.
N
N
So,
in
addition
to
that,
so
here
pgp
is
tended
to
send
the
bonding
with
a
node
ID
of
n
to
the
adjacent
node
of
another
n.
So
after
this,
when
node
error
fails,
the
adjacent
nodes
can
provide
protection
fast
for
protection
for
the
failure
of
load
n.
So
here,
when
load
error
fails,
P1
will
detect
the
failure
P1,
because
P1
have
information
for
bonding
and
also
know
the
ID
of
another
n.
N
So
next
page
so
right
now
our
PHP
has
extended
to
distribute
routing
policy
through
tunnel
in
cap
attributes.
So
here
we
just
Define
a
subator
v
called
bonding
protection,
Superior
V.
Basically,
this
subterfly
just
contains
the
node
ID
of
data
node
and
something
so
when
pgp
distributes
binding,
which
is
encoded
by
the
funding
sheet
and
second
list
to
a
node
n
pgp
will
also
distribute
this
funding.
Plus
data
n.
N
So
the
Json
node
can
provide
protections
of
failure
of
that
or
then
for
the
funding
next
page.
So
the
extension
is
the
first
symbol.
We
just
Define
a
funding
protection,
supportive
V.
Basically,
this
abundant
protective
server
V
can
find
some
flags
and
then
node,
ID
subtr
V.
So
this
lotus
idwv
in
pgp
will
just
use
the
pgp
ID
so
which
contains
pgp
node
ID.
S
I
actually
forgot
to
use
the
app
to
jump
in
the
gear.
So
sorry
about
that
I
understand,
Nokia,
I
actually
didn't
read
this
draft,
but
I
read
the
one
in
the
pce
working
group
and
obviously
it's
very
similar
I
just
had
a
general
question
that
wasn't
clear
to
me
when
you
program
to
the
neighboring
routers.
Are
you
informing
the
neighboring
routers
of
the
entire
Sid
list
that
The
Binding
set
is
being
programmed
with.
N
S
N
Yeah
that
doesn't
matter
so
P1
only
chaos,
though
the
those
green
ones.
So,
first,
first
the
P1
just
replace
the
binding
sheet
with
those
see
the
list
for
green
one
right
and
then
so.
P1
has
the
whole
second
release
and
then
P1.
We
are
just
a
good
rid
of
the
the
seed
for
data,
failed,
node
and
then
go
to
the
next
hole.
That's
all
right!
The.
S
Likes
one
he
doesn't
count,
I
do
think,
there's
a
gap
here.
Oh
I
can
follow
it
up
on
the
list.
Yeah
yeah.
We
can
go
to
detail
at
these,
have
details
and
then
one
other
detail
just
to
kind
of
throw
in
the
mix.
The
actual
label
stack
of
The
Binding
Sid
could
also
have
nested
binding
SIDS.
So
in
that
case,
you're
even
further
down
the
chain
of
trying
to
understand.
Where
do
you
pop
out
on
the
other
end
of
The
Binding
set
so.
S
T
I
want
to
talk
about
the
general
example
use
case.
First,
let's
say
you
have
a
VPN
with
10ps
or
100ps,
and
for
that
VPN
we
have
a
route
Target.
We
call
it
rt1
the
route
Target,
it
is
an
extended
Community,
say
ec1
with
a
subtype
0x2,
in
this
case
rt1
and
ec1.
They
are
the
same
thing,
but
when
we
say
a
route
Target,
we
emphasize
that
it
is
a
extended
Community
for
purpose
that
is
used
to
control
the
propagation
and
importation
of
the
routes.
T
So
to
control
the
route
that
to
be
propagated
to
PE
when
owning,
we
want
to
use
a
different
route
targets,
we
say
rt2
and
to
tell
the
pe1
that
this
route
is
related
to
this
VPN.
We
attached
different,
extended
Community
for
that
purpose.
So,
in
this
case,
rt2
cannot
be
the
same
as
rt1,
because
rt1
will
get
the
routes
to
all
the
peas
we
here
we
want
to
direct
the
route
on
into
Pua.
T
T
If
we
change
it
back
to
0
x,
0
2,
which
indicates
of
RT,
then
we
get
original
RT
back
and
we
actually
have
the
got
a
subtype
0x15
assigned
for
this
purpose.
So
if
you,
if
you
have
a
RT
which
is
subtype
0x2,
you
should
simply
change
that
subtype
to
0x115,
you
get
an
extended
Community
corresponding
to
that
route.
Target
next
slide,
please.
T
T
There
are
two
other
example:
use
cases
documenting
the
draft.
In
fact,
just
before
this
IDR
meeting
a
few
of
us
were
talking
about
another
specific
use
case
again,
it's
really
for
the
general
use
case,
so
General
use
case
is
that
giving
an
RT
derived
extended
community
community
and
use
it
for
whatever
purpose
you
want
to
use
for
next
slide.
T
So
this
document
only
specifies
the
derivation
of
this
extended
Community
from
a
route
Target.
By
using
this
new
0x15
subtype,
we
do
not
specify
how
it
will
be
used.
It
can
be
very
creative
you
or
whatever
our
use
case
you
may
have.
It
is
a
simple
idea.
We,
the
co-authors
here
we
believe,
is
ready
for
the
working
group.
Adapt
adoption
so
comments.
H
Ac
window
I,
just
I
just
got
one
question:
would
you
still
need
to
document
in
an
ITF
I
mean
IDR
draft.
The
specific
usage
like
you
have
these
three
you
still
would.
This
would
just
make
the
assignment
automatic
right
from
our
from
the
art
from
RT's
existing
for
the
birth,
the
assignment
I
mean
not
for
the
RT
and
you
haven't
existing
RT
and
you
want
to
derive
it
for
a
use
case.
That
use
case
would
still
have
to
be
documented
in
a
draft.
Wouldn't
it.
T
G
U
U
We
will
rush
to
the
presentation
because
it's
it's
discussed
in
detail
in
the
interim,
and
here
we
just
wanted
to
refresh-
and
we
may
not
have
much
time
so
we'll
go
through
the
background
problem
statement
and
the
layout
of
the
multinational
stop
attribute
propagation
scope,
error
handling,
Etc,
and
while
discussing
that,
we
will
discuss
the
use
cases
in
mind
next
slide.
Please.
U
U
U
U
Routes
either
with
the
from
different
peers
or
if
it
is
from
the
same
year,
we
use
add
path
to
advertise,
multiple
paths
and
each
one
of
those
routes
have
its
own
next
house,
and
this
has
worked
so
far,
and
there
is
some
increased
rib
scale
specifically
about
scale
implications
for
it,
and
another
thing
is
like
all
the
for
all
the
different
mechanisms
that
have
been
specified
in
the
previous
slide.
Add
path
really
caters
to
the
next
stop
and
MP
reach
attribute
where
the
next
stop
is
carried
in
those
attributes
for.
O
U
How
Next
Top
is
carried
ad
path
is
kind
of
unspecified,
the
procedures
it
may
work
or
it
may
not
work,
and
then
how
do
we?
When
we
receive
all
these
routes,
then
we
do
multipath
or
protection
based
on
the
local
config.
So
as
of
all
how
we
gather
the
information,
that's
required
to
program
the
FIB
or
consume
and
program
the
forwarding
it's
like
organically
grown
and
it's
in
different
portions
of
the
bgp
route
and
in
local
configuration.
U
C
U
U
So
we
have
the
signaling
coming
on
the
route
and
the
local
configuration
in
combination
giving
an
implementation
what
it
needs
to
program
the
Fib.
So
it
has.
This
mechanism
has
the
inability
to
first
of
all
advertise
more
than
one
next
stop
in
a
route,
and
it
is
not
expressive
in
the
sense
that
the
advertiser
can
control
the
FIB
by
installing
routes
with
desktops
which
have
various
relationships.
U
So
even
if
we
are
able
to
advertise
multiple
next
stops
and
AD
path,
we
are
not
able
to
express
the
relationship
between
the
different
next
stops
and
it's
not
easily
extensible
for
newer
endpoint
types
and
calculation
types
Etc.
So
if
we
had
these
properties,
maybe
we
may
be
able
to
use
bgp
as
an
API
as
a
standard
API
to
the
receiver's
FIP
for
a
different
type
of
payloads
and
and
also
if
we
have
a
uniform
way
of
expressing
the
tunnel.
U
The
encapsulation
info
for
different
address
families
like
Safi
one
cannot
carry
labels
today,
then
we
will
be
able
to
make
the
core
simpler.
We
don't
need
service
routes
in
the
core
service,
reps
can
be
close
to
the
edge
and
that
will
be
extending
the
principles
of
a
BJP
free
course.
Next
slide,
please.
U
Yeah
so
in
in
some
cases
we
want
to
advertise
multiple
labels
and
that
helps
in
the
label,
label,
oscillation
avoidance
and,
in
some
other
cases,
the
semantics
of
a
downstream
allocated
label.
If
it
is
known
by
the
receiver,
they
may
be
able
to
visualize
the
network
better
or
they
may
be
able
to
do
EP
decisions
better,
and
then
there
is
a
problem
slightly
unrelated
to
the
next
half
level
scope.
U
It's
at
the
route
level,
where,
if
it's
an
option,
C
domain,
we
don't
have
local
preference
like
control
for
it
today,
because
local
preference
is,
though
it
it.
It
seems
like
it's
intended
to
the
and
designed
for
use
in
a
single
domain,
which
is
like
a
single
as
or
a
confederation
and
option.
C
domain,
though
it
is
a
single
administrative
domain,
but
we
don't
use
local
preference
for
it
because
it
is
going
over
ebgp
session
and
bgp
doesn't
have
a
way
of
identifying
which
set
of
ass
is
part
of
that
domain.
U
U
U
So
it's
an
optional
non-transitive
attribute
and
its
usage
is
also
negotiated
with
a
new
bgp
capability
and
it's
a
tlvi's
format
which
is
extensive,
extensible
for
newer
endpoint
type,
encapsulation
types,
forwarding
actions
and
argument
types
and
it
can
carry
one
or
more
next
top
instructions
and
it
can
basically
be
used
as
a
API
to
a
bgp
based
API
to
the
receiver
script.
So
next
slide
please.
U
So
this
is
the
bird's
eye
view
of
the
attribute
itself.
Basically,
the
multinational
stop
attribute,
it
has
a
propagation
scope,
Checker
and
then
it
has
one
or
more
mnh,
tlvs
and
htlv.
It
has
a
type
and
it
has
an
extra
forwarding
information
and
the
next
of
forwarding
information
itself
is
one
or
more
forward
forwarding
instructions,
and
the
forwarding
instruction
is
a
forwarding
action
and
forwarding
arguments.
U
So
forwarding
action
is
things
like
forward
pop
push
Swap
and
the
forwarding
arguments
are
like
what
are
the
arguments
that
you
required
to
complete
that
action
like
where
to
forward
to
what
kind
of
encapsulation
to
be
used?
So
if
you,
if
you
think
about
it
so
today,
whatever
we
have
is
the
next
stop
is
the
forwarding
instructions,
and
this
is,
and
that
is
applicable
for
IP
routes
for
mpls
labels.
U
That
cannot
be
used
because
we
don't
have
a
way
to
specify
pops
wrap
push
as
part
of
the
next
stop,
whatever
labels
that
we
receive
as
next
up
or
in
the
nlra
8277
encoding.
That
is
used
as
a
push.
So
for
that
the
action
is
implicitly
pushed,
so
those
forwarding
actions-
they
are
just
enumerated
here
and
the
propagation
scope.
Checker
is
what
allows
restricting
the
propagation
scope
of
the
attribute
so
that
we
can
realize
the
domain
local
preference
kind
of
functionality
next
slide.
Please.
U
So
initially
this
attribute
was
transitive
and
after
the
discussions
we
made
it
non-transitive
and
it
also
carries
the
advertising
protocol
next,
stop
which
can
be
used
to
know
if
the
message
is
valid,
whether
it
was
added
by
the
router
who
rewrote
the
next
hub.
So
because
it's
made
non-transitive
and
it
is
also
negotiated-
the
capabilities
negotiated
in
the
open
message.
The
question
that
comes
is:
do
we
need
this
anymore?
Maybe
because
it
is
more
con.
U
The
propagation
scope
is
more
conservative,
now
I'm
wondering
whether
we
can
remove
the
advertising
pnh
portion
from
the
attributes.
So
that's
one
question
that
comes
after
doing
a
little
thinking,
and
so,
even
among
the
speakers
that
understand
the
MNS,
the
advertisement
is
controlled
by
this
propagated
scope.
Checker.
So
we
by
default
don't
arrest
to
any
any.
A
U
U
So
these
are
the
types
that
are
defined
today
so
type
one
is
the
Upstream
signal
primary
forwarding
path.
Type
2
is
like
up
Sim
signal,
backup
founding
path.
So
today,
whatever
we
do
with
the
regular
next,
stop
is
type
one
we
can
think
about
it
like
that
and
then
type
4
is
the
domain.
Downstream
signal
label
descriptor
and
all
these
about
types.
They
have
a
forwarding
information
Theory,
which
will
describe
what
is
the
kind
of
forwarding
actions
and
arguments
and
type
3
is
domain,
local
preference.
U
G
U
There's
another
question
that
I
had
whether
we
need
to
add
an
indication
like
a
partial
bit
which
lets
a
receiver
to
know
whether
a
particular
type
has
traversed
the
speakers
which
don't
understand
it
next
slide,
please
yeah.
So
this
is
the
list
of
forwarding
information.
This
is
what
describes
the
next
stop
and
it
contains
one
or
more
desktop
leg
elements.
Next
of
ordering
instructions
next
slide,
please
yeah.
U
So
this
is
the
forwarding
action,
and
here
we
see
the
different
forwarding
actions
that
are
possible
today,
and
some
of
them
which
may
come
up
in
future
so
replicate
is
one
example
where
I
mean
today,
we
don't
do
much
just
like
it's,
it's
like
unicast
or
ecmp,
or
active
backup,
or
you
can
do
a
replicate.
So
everything
that's
possible
today
is
enumerated
here.
If
a
new
forwarding
action
comes
today
at
tomorrow,
we
we
can
just
extend
it
here
and
each
forwarding
action
has
one
or
more
arguments
next
slide,
please.
U
So
these
are
the
type
of
endpoint
identifiers
that
are
available
today.
So
ipv4
address
this
ipv4
next,
stop
address
or
IPS
is
the
stop
address
which
identifies
a
node
and
mpls
label,
either
Upstream
allocated
or
Global
scope,
or
we
can
say
forward
to
a
particular
forwarding
context
at
the
receiving
node
or
a
forwarding
context
identified
by
the
RT
at
the
receiving
node
and
even
the
IP
address,
which
identifies
a
node.
U
For
example,
when
Linda
was
talking
about
the
site
based
forward
inside
any
base
forwarding,
it
occurred
to
me
that
let's
say
you
have
this
IP
address
today
an
IP
address.
What
we
have
here
is
identifies
a
node,
but
let's
say
we
have
a
different
scope
where
we
say
we
send.
This
information
send
this
traffic
to
a
site
and
there
we
have
an
IP
address
that
identifies
a
site,
not
a
particular
device.
So.
U
U
One
of
them
is
proximity
check
which
can
enable
the
sender
to
say
whether
this
next
stop
should
be
restricted
to
be
single
hop
or
it
should
be
expected
to
be
multi
multi-hop
or
if
both
of
these
bits
are
cleared,
then
it'll
take
epgp
single
up
and
ibjp
is
multi
half
just
like
what
it
is
today
and
other
constraints
like
the
transport
class
ID,
that's
a
color
or
the
load
balance
Factor.
The
different
constraints
can
be
given,
and
these
constraints.
U
The
end
point
that
has
been
communicated
with
next
slide:
please
yeah.
So
these
are
the
payload
encapsulation
info,
signaling
tlb,
so
it
enumerates
the
different
encapsulations
that
we
have
today:
common
ones,
the
MPS
label
info,
and
so
the
things
like
ELC
capability
or
other
capabilities
of
mpls
related
capabilities
are
encoded
along
with
this
MPS
label
info.
U
So
just
that
the
information
is
like
scoped,
closer
to
where
it
belongs,
and
then
other
others
are
like
Sr
mpls
index
level
index
and
srv6
hit
and,
in
addition
to
encapsulation
for
for
every
end,
point
the.
What
are
the
attributes
that
the
endpoint
has
either
available
bandwidth
or
some
something
else
that
may
want
to
advise
in
future.
U
Next
slide,
please
so,
each
as
we
see
that
each
forwarding
instruction
has
a
forwarding
action,
tlv
and
a
set
of
arguments,
so
each
forwarding
action
can
specify.
This
is
the
minimum
set
of
arguments
that
is
required
and
we
see
that
this
mechanism
is
like
very
flexible
so,
but
it
carries
the
information
closely
scoped
so
that
we
can
set
rules
based
on
forwarding
action,
which
are
the
minimum
set
of
arguments
that
needs
to
be
there,
so
that
the
forwarding
in
information
is
valid
and
what
the
rules
based
on
that.
U
So
generally,
the
error
handling
mechanism
is
followed
in.
This
draft
is
like
attribute
discard
approach,
so
try
to
deal
gracefully
with
the
errors
as
much
as
possible
and
unknown
tlvs
are
ignored
and
propagated,
and
if,
if
there
are
tlbs
which
are
received-
and
they
are
not
able
to
be
processed
logged
with
enough
diagnostic
data
and
worst
case,
keep
the
attributed
discard
discard
mode
and
don't
use
it,
for
example,
because
we
are
able
to
advertise
multiple
next
stops
in
a
single
route.
U
So
if
a
receiver
is
not
able
to
process
that
many
next
house
based
on
the
kind
of
acmp
he
supports,
so
you
can
just
assume
that
the
whole
attribute
is
in
this
card.
So
it's
a
more
conservative
approach
that
is
currently
specified
in
the
draft.
We
could
say
that
okay,
you
can
install
whatever
acmp
depth
that
you
can,
and
so
those
are
the
things
that
we
need
to
discuss
right.
There
are
more
details
about
our
handling
in
section
6.,
so
yeah.
G
E
G
U
U
All
those
things
will
be
calculated
for
all
these
Tech
stops
as
well,
because
these
all
of
these
are
also
next
stops
and
where,
if
you
have
a
different
type
of
endpoint
and
which
has
reachability
propagated
via
different
mechanism,
then
that
will
specify
how
to
calculate
those
equivalent
igp
cost
or
reachability
reachability
verification.
And
if
none
of
the
legs
are
reachable,
then
this
attribute
is
not
usable
and
then
the
bgp
route
will
also
be
unusable,
because
that
will
mean
that
the
next
stop
address
carried
in
the
actual
next
stop
attribute
is
also
unusable.
U
I
think
I
hope
that
answers
the
first
question
and
about
the
second
one
was
about
yeah
transitive
non-transitive
right.
So
we
just
wanted
to
be
conservative
in
the
sense
that
yeah,
so
the
whole
idea
is
about
being
conservative
so
that
the
attribute
never
leaks
out
into
the
internet.
So
that
is
why
we
wanted
to
have
it
as
non-transitive
though
it
may
be.
U
A
hurdle
is
for
the
initial
implementation,
where
we
may
not
have
all
the
RRS
or
asbrs
implemented
this
feature,
but
once
we
reached
across
that,
then
I
think
it.
It
will
be
further
longer.
If
you
take
a
longer
view,
it
will
be
safer
to
have
it
have
that
confidence
that
it's
not
going
to
leak
into
the
internet
whatever.
So
that's
why
it
was
kept
us
non-transitive.
A
We
see
a
little
bit
of
theme
of
this
also
inside
of
the
bgp
car
proposal,
with
the
actual
NRI
trying
to
bind
that
to
the
individual
destinations
as
Kyle
Roger
points
out.
There's
other
proposals
like
things
we
do
in
flow
spec
and
outside
of
bgp.
You
know
those
of
you
who've
done
work,
for
example
in
Google's,
g-riby
interface.
A
They
recognize
the
next
top
groups,
for
their
programming
looks
a
little
bit
like
some
of
what
Kali
Raj
is
doing
for
multi-nextop
here
in
bgp,
so
it's
a
side
effect
we're
entering
a
space
where
we're
looking
to
see
what
do
we
want
to
actually
carry
in
B2B
for
this
information,
and
do
we
continue
encoding
this
as
small
incremental
changes
to
the
bgp
update
that
we
have
today?
Or
do
we
start
looking
at
what
you
know?
Basically,
the
update
format
is
for
our
future
extensions.
L
I'm
swadesh
from
Cisco,
we
I
think
we
should
Define
the
scope
because,
as
we
see
today,
bgp
carry
a
next
stop
and
now
it's
a
proposal
to
carry
a
multiple
next
stops.
It
impacts
bgp,
best
path.
How
paths
are
invalidated
in
general,
bgp
I'm,
not
sure
how
how
we
are
going
towards
it.
This
top
doesn't
clarify
any
of
those
stuff
at
all
and
bgp
packing.
We
are
carrying
a
label
forwarding
info
encapsulation,
everything
is
attribute
and
this
proposals
will
be
carried
with
bgp
all
the
surface.
L
So
whatever
we
are
developed
for
10
years
15
years,
it
will
impact
badly
so
badly.
I'm
saying
the
word
so
and
ucmp
today.
If
I
have
two
such
path,
how
will
I
invalidate
I
have
four
next
stop
in
One
path
for
next
stop
another
path
or
will
I
do
tracking
invalidation?
So
I'm
not
sure
we
should
be
looking
this
with
more
concern
than
if
it
is
a
I
think
scope
has
to
be
defined
before
we
even
move
ahead
with
interesting.
E
A
So,
let's
please
have
this
discussion
on
the
mailing
list.
There's
a
lot
of
good
content
here
and
again
we're
looking
at
what
we
do
the
future,
even
if
it
isn't
necessarily
the
rest
of
this
draft,
but
this
draft
is
a
good
place
to
start
having
the
discussion
hi
dear,
thank
you
for
this
session.
We
will
see.