►
From YouTube: IETF109-IDR-20201120-0900
Description
IDR meeting session at IETF109
2020/11/20 0900
https://datatracker.ietf.org/meeting/109/proceedings/
A
B
A
Thank
you
for
you.
Thank
you.
Meat,
echo,
put
up
a
thing
that
said.
Are
you
speaking
we're
not
getting
any
sound?
I
believed
it.
What
a
fool!
Okay!
A
A
Here's
our
note
well,
if
you're
in
this
meeting
you're
somehow
agreed
to
this
thing,
because
it
was
on
some
click,
wrap
and
you've
are,
are
presumed
to
have,
read
and
agreed
to
all
this
stuff.
If
you
haven't
go
read
it.
A
A
So
sue,
do
you
want
to
talk
to
this.
C
C
So
if
you
have
also
with
virtual
I
gift,
I
would
like
to
make
sure
I
get
all
the
adoption
requests
if
you've
got
an
adoption
request,
please
send
me
a
note
and
a
yang
model
has
received
shares
comments
from
the
young
doctors.
I'd
love
to
know.
If,
if
there's
any
comments,
I
still
have
a
couple
people
to
check
with.
C
I
will
try
to
arrange
some
conversations
with
you
one-on-one
and
then
perhaps
you
may
see
a
short
g
I'd
like
to
collect
comments
on
the
pgp
gang
model,
so
we
can
wrap
that
one
up
next
john.
C
Find
it
okay,
where
are
we
well
flow?
Spec
5575,
fists
and
flow
spec
b6
are
very
close
to
publication.
We're
crying
we're
nitpicking
with
some
of
the
isg
members,
but
that's
good.
We
wanted
to
make
sure
this
time.
We
don't
have
to
go
back
and
do
the
the
version
ones
it's
time
to
begin
work
for
people
who
are
interested
in
flow,
spec
version,
2
watch
for
a
call
for
presentations,
and
perhaps
an
interim
I'd
like
to
kick
things
off
on
interims,
because
this
is
a
short
time
sign.
C
The
ipsec
tunnels
are
still
progressing
along
I'll.
Go
through
that
and
bgpls
will
talk
about
streamlining
the
auto
comp
work
is
started,
the
chairs
will
restart
and
I
think
we're
pretty
much
got
one
route
league
protection
document
and
girl
and
idr
are
working
together
next
slide
the
ipsec
tunnels.
This
is
just
a
report
from
someone
who
has
been
trying
to.
C
Work
with
all
three
sets
of
authors,
we
had
two
an
idr
one
and
best.
I
still
see
three
different
use.
Cases
for
these.
My
goal
has
gone
down,
has
as
a
sort
of
shepherd
trying
to
help
them
is
to
see
if
we
can
share
tlbs
if
they're
this
subtleties,
if
they're
the
same
information,
but
the
critical
thing
is
that
they
get
reviewed
by
the
security
area
and
or
security
directed,
so
that
when
we
come
back
to
the
isg
with
them,
we're
not
spending
time
iterating
there.
C
They
also
be
based
on
draft
itf
id
or
tunnel
and
caps,
and
I
look
for
clear
specification,
a
non
goal
to
force
these
three
different
use
cases
into
one
tunnel
type
next
side,
john
and
now
adrian
brought
us
the
bgpls
registries.
Adrian.
Would
you
please
lead
this
discussion.
D
Yeah
sure
so
you
may
remember,
we
had
a
a
little
draft
to
fix
up
the
bgpls
registry
allocation
policy,
so
this
was
all
set
up
originally
in
7752,
as.
D
That's
interesting,
that's
wrong,
so
they
were
all
all
set
up
as
specification
required
with
a
approval
by
a
designated
expert
and
the
guidance
to
the
de
they're
asked
for
a
stable
document,
as
described
in
rfc
5226,
which
is
now
eight
one.
Eight
one,
seven
four.
I
can't
remember
so.
There's
lots
of
debate
about
whether
an
internet
draft
qualifies
as
a
stable
document
and
alvaro
pointed
out
that
idr's
not
the
place
to
have
this
sort
of
debate.
D
So
we
really
have
two
options.
Moved
to
expert
review.
Expert
review
simply
relies
on
the
designated
experts,
which
is
what
we
had
done
in
in
the
draft
in
question,
or
we
could
move
back
to
specification
required,
but
tighten
the
the
guidance.
D
So
I
kicked
the
list
and
very
many
thanks
to
bruno
les
ac
and
kittan
for
for
for
chiming
in
and
it
looks
like
we're
moving
very
fast
to
yes,
let's
be
expert
review,
but
let's
tighten
up
what
the
d
is
allowed
to
do
in
line
with
rsc
7370,
which
did
something
similar
for
an
isis
registry.
D
D
D
C
I
being
at
the
speed
at
which
things
come
in
and
off
of
the
adq
I'd
like
to
keep.
What's
on
the
queue
on
the
queue,
then
the
a.d
can
bash.
But
that's
that's
my
single
co-chair,
very
tactile
viewpoint,
john
or
working
group.
Any
other
thoughts.
E
Okay,
so
is
it
me
or
john
me?
Okay,
yes,
I'm
sorry,
my
q
is
kind
of
slow,
but
you
know
there's
a
lot
of
documents.
Tunneling
caps
took
a
long
time,
yeah,
whatever
I
have
a
lot
of
excuses.
E
What
I
want
to
say
is
that
I'm
not
opposed
to
two
documents
or
whatever
you
guys
want.
What
I
did
want
to
point
out
is
that
7370,
which
adrian
mentioned,
is
the
guidance
for
actual
review
for
the
isis
registries,
and
basically,
what
that
says
is
that
it
is
basically
7120
but
handled
by
the
expert
review
handled
by
the
experts.
In
other
words,
drafts
need
to
basically
be
adopted
by
the
working
group
before
anything
gets
adopted.
E
E
With
that
little
caveat
of
maybe
there's
no,
not
enough
clarity,
different
places
about
whether
an
idea
is
accepted
or
not.
That
is
totally
up
to
the
these,
and
I
know
that
it's
not
that's
not
documented
anywhere,
but
you
know
I'm
sure
that
the
current
des,
which
adrian
is
one
and
the
chairs
and
me
and
ayanna,
wouldn't
be
opposed
to
any
of
that.
So
having
said
that,
if
we're
gonna
go
with
seven
three,
seventy
like
expert
instructions-
it
is
pretty
much
the
same
thing
that
you
have
today.
E
If
one
of
the
objectives,
which
is
what
I
understood
from
the
draft,
was
to
speed
things
up
and
let
people
request
code
points
without
being
working
group
documents,
then
that
doesn't
necessarily
get
you
there
now
again,
assuming
that
737
is
taken
the
way
it
is,
it
can
still
be
modified.
So
I
just
want
to
point
that.
C
C
Did
you
have
any
other
comments
I
think
alvaro?
I
wasn't
trying
to
say
that
things
were
really
slow,
but
I
agree
that
tunnel
end
caps
took
a
lot
of
time
out
of
both
alvaro
john
and
I
it's
a
good
and
meaty
speck.
I'm
amazed
with
some
stuff
john's
done.
Okay,
adrian
any
more
final
comments.
Otherwise
I'll
go
on
to
some
more
chair.
D
C
C
I
can
free
range
people
can
read
it
from
the
rest.
Why
don't
you
try
one
more
time.
A
C
Okay,
john's
gone
someplace,
okay,
folks,
the
the
remainder
is
give
me
just
one
second,.
C
C
Okay,
we
have
the
auto
conf
design
team
and
this
one
I
hope
you
all-
will
take
a
look
at
it.
Sort
of
got
installed
partly
many
things,
but
we're
going
to
give
a
push.
I
have
a
couple
dates
in
december,
8th
and
15th
if
you're
on.
Thank
you,
john
you're,
back
if
you're
on
the
auto
conf
design
team-
and
you
have
strong
feelings
for
a
particular
date
in
december-
please
send
we
will
try
to
get
some
meetings
and
get
an
initial
statement
and
design
document
out.
C
C
The
last
one's
just
a
big
thanks
to
g
he's
done
a
great
job
of
organizing
and
shepherding
things
we
wanted
to
make
sure
to
thank
him.
He
created
our
agenda
and
organized
our
speakers
and
helped
john
and
I
stay
focused
on
the
tunnel
and
caps
back.
Thank
you,
john.
I
think
we
should
go
to
our
first
any
comments.
Folks
on
any
of
the
points
in
the
chair,
slides
or
the
status.
C
To
no
comments
in
any
of
my
things
were
going
to
go
on
for
the
first
section.
C
F
Okay,
hi
can.
Can
you
hear
me
okay
just
so.
This
is
a
update
on
the
segment
routing
t
policy,
so
bgp
signaling
of
sr
policies.
Next
slide.
Please.
F
Just
a
quick
overview
not
going
to
go
to
all
the
details,
so
this
was
presented
a
year
ago
now
and
we
have
had
you
know,
feedback
and
inputs
a
lot
of
discussions
on
their
list
as
well,
and
all
of
those
have
been
updated
or
captured
in
this
update,
quick
point
that
the
the
base
are
the
base
pack
in
spring.
You
know
which,
for
which
the
bgp
extensions
are
covered
here,
is
also
kind
of
getting
ready
for
working
group
last
call
in
spring
next
slide.
F
F
There
was
some
confusion
about
the
policy
name
tlv
that
was
there
existing,
and
you
know
that
was
actually
the
sr
policy
candidate
path,
but
then
based
on
requirements
and
requests.
We
also
added
the
policy
name
again
for
alignment
with
sr
policy,
draft
discussion
about
the
route
origin,
community
and
its
usage
to
indicate
the
originator.
So
we've
added
that
in
the
draft
and
then
we'll
go
about
the
changes
related
to
srv6
in
the
next
slide.
F
But
other
thing
I
would
like
to
flag
quickly
is:
we've
seen
the
tunnel
encaps
draft,
you
know
getting
fixed
up
and
as
part
of
that,
the
ayana
registration
is
happening
there
for
the
color
extended
community.
So
this
draft
has
now
been
updated
to
refer
there,
and
you
know
diana
section
text
has
been
updated.
F
F
The
network
programming
is,
you
know,
with
the
isd
awaiting
you
know,
last
discuss,
but
what
we
did
over
the
past
year
is,
you
know,
updated
to
line,
so
we
have
a
srv6
binding
set
tlv,
and
this
is
because
the
current
binding
ctl
we,
you
know
only
we
could
have
only
one
binding
set
associated
with
sr
policy,
but
when
we
get
to
srv6,
we
can
have
you
know
more
than
one
with
possibly
different
behaviors.
F
So
all
that
clarification
and
text
has
been
added
and
the
segment
types
have
been
updated
for
the
optional
signaling
of
you
know,
algorithm
behavior
things
like
that,
so
that
segment
type
changes.
What
it
has
resulted
in
is
that
the
previous
type
tlvs
we've
had
to
you
know
deprecate
them.
F
We
had
a
check
with
some
of
the
vendors
and
you
know
whether
they
are
deployed
and
used
and
all,
and
we
got
the
indication
that
they
may
not
be
implemented
or
deployed
fully
as
yet,
but
just
to
be
safe.
The
proposal
is,
to
you
know,
deprecate
them.
They
are
kept
in
the
appendix
so
look
forward
to
feedback
from
the
working
group
on
on
this
one
next
slide,
please.
F
So
next
step
is,
I
would
say,
preparing
for
the
working
group
last
call.
The
implementations
have
been
updated
with
two,
but
we're
aware
that
there
are
more
so
I
would
request
to
please
update
and
I
think
it
would
be
good
if
we
can
plan
a
working
group
last
call
for
this,
preferably
after
the
base.
One
is
done
in
spring.
A
Looks
like
we
have
a
comment
from
g.
Please
go
ahead.
G
Can
you
hear
me
yes,
yes,
hi
g
hi
regarding
this
change
in
the
segment
types
you
know,
there's
also
a
draft
on
the
tlsp
distribution
to
report.
F
G
F
Yeah,
yes,
you
are
correct
g.
I
think
we
need
to
work
on
that
as
well.
We'll
we'll
work
on
that
I
mean
you
are
also
the
co-author
that
will
work
on
that
option.
A
Okay,
seeing
nobody
else
in
the
queue
I
guess
we
can
move
on
to
our
next.
F
One
yeah,
so
this
is
an
update
on
the
rfc
7752,
the
bgpls
this
that
you
know
adrian
referred
to
earlier
next
slide,
please
so
we
have
had
since
the
rfci
publication,
and
even
before
that
we
have
had
you
know
a
lot
of
implementation
and
deployment
now
with
lot
of
use
cases,
and
there
has
been
a
discussion
on
the
list
as
well
as
a
lot
of
inputs
from
various
folks,
including
our
ad,
when
he
he
was
reviewing
some
of
the
segment
routing
extensions,
that
there
are
issues.
F
So
we
started
around
idea
104
this
thing
to
try
to
fix
them
up,
and
you
know
the
draft
was
presented
at
105
a
little
over
a
year
ago
and
then
it
was
adopted.
So
it's
been
a
year
now
more
than
a
year.
So
I
would
like
to
thank
everybody
again
for
a
lot
of
feedback
and
input
a
lot
of
it
on
the
list,
but
there
was
also
a
lot
of
off
list
comments.
Next
slide.
F
F
F
I
didn't
want
to
go
over
all
of
that,
but
I
would
like
to
point
that
the
appendix
has
list
of
all
the
changes
from
the
base
7752,
it's
like
a
kind
of
a
summary
and
then
actually
you
could
run
a
diff
there's
a
link
there
to
check
what
has
actually
changed
from
the
base
pack
as
well.
F
F
So
so
ayanna
register
in
our
considerations
you
know
we
discuss.
There
is
a
draft
that
you
know
we
are
it's
in
ad
evaluation,
whatever
gets
updated
or
accepted
there
will.
You
know
also
incorporate
that
here
in
in
this
in
this
draft.
F
F
And
this
is
the
last
one:
really
all
all
issues
and
all
concerns
have
been
addressed.
Please
let
know
if
anything
was
missing.
F
I
know
it
was
a
difficult
time
over
the
past
nine
months
this
year,
but
you
know
in
case
you
wanted
to
so
there
was
a
bit
of
silence,
but
if
there
is
anything
else
that
needs
to
be
added,
please
do
let
know
I'll
also
poll
the
list
after
this
meeting
last
slide,
I
think,
is
the
next
one.
F
So
if
I
mean
how
do
we
go
about
this
and
wanted
to
check
here
whether
we
need
to
keep
this
this
document
open?
If,
yes,
for
how
long?
If
no
then,
maybe
next
year,
early
next
year,
we
start
planning
for
a
working
group
last
call
because
I'm
not
sure,
if
helps
just
to
keep
the
document
open,
look
to
inputs
from
the
working
group
chairs
as
well.
C
John
I'll
jump
in
here
real
quick.
I
always
find
that
a
working
group
last
call
knocks
out
documents
when
knocks
out.
Excuse
me
comments
to
documents,
so
I'd
go
for
december
or
january
for
working
group
class.
Call
whenever
you
finish
the
other
things
john,
do
you
have
any
other
comments
about
that.
A
I
was
just
gonna
give
my
answer
to
the
do.
We
see
a
need
to
keep
the
biz
document
open
for
more
time,
and
my
answer
is:
if
you
feel
it's
done,
then
I
don't
see
it.
I
need
to
keep
it
just
arbitrarily
open.
A
I
you
know
we
we
need
to
have
a
proper
working
group
last
call
and
and
know
that
some
people
have
reviewed
it.
But
beyond
that
now,
let's
let's
get
it
done,
I
mean
if
anybody
else
thinks
otherwise,
please
put
yourself
in
the
queue
but
I'd
say
yeah.
What's
you
said,
let's
go
ahead
with
the
last
call
fairly
promptly,
and
I
see
adrian
volunteering
to
review.
Thank
you
adrian.
A
A
H
That's
what
I
wanted
to
I'm
going
to
present
on
flow
spec
for
mobile
traffic
next
slide.
Please.
H
So
the
if
the
file
name
for
historic
reasons
has
nvo3
in
it,
but
it
it's
actually
designed
to
cover
flows
for
a
wide
variety
of
tunnel
types
that
are
listed
there.
One's
currently
in
the
draft
will
be
possible
to
add
more,
I
suppose,
but
I
think
it's
got
a
pretty
good
covering
and
it
allows
you
to
match
on
the
actual
tunnel
header
fields
of
various
sorts,
as
well
as
the
various
headers
that
are
just
beyond
the
tunnel
header.
Typically
ip
headers,
just
beyond
the
tunnel.
H
Header
could
be
other
things
and
you
can
as
well
match
on
the
ip
or
whatever
header
in
front
of
it.
There'll
be
examples
and
stuff
in
a
little
bit
later
in
the
presentation-
and
you
indicate
all
this
with
a
happy
safy
pair
using
a
new
safi
that
indicates
it's
a
flow
spec
for
tunnel
traffic
and
the
affi
indicates
what
you're
going
to
match
right
at
the
very
beginning
of
the
packet
or
the
leaning
of
the
packet
inside
the
vpn.
H
If
it's
a
case
where
you're
matching
vpn
traffic,
so,
for
example,
you
might
have
a
ipv4
or
a
fee,
but
the
saffy
says
tunnels.
That
means
you've
matched
an
initial
ipv4
header,
but
then
you
would
be
able
to
match
various
forms
of
following
that
tunnel
header
and
if
you
want
to
go
beyond
that
and
match
the
headers
just
beyond
the
tunnel
header
next
slide.
H
So
this
is
just
how
this
depends
on
other
drafts,
and
I
annotated
this
with
what
I
believe
is
the
current
status
of
the
different
slides
next
slide.
Please.
H
So
this
has
been
changed.
The
last
presented
version
was
08,
so
0809
or
changes
in
the
precedence
rules
to
clarify
things.
Obviously,
only
when
a
tunnel
source
back
is
involved,
existing
rules
cover
other
cases
and
various
editorial
improvements
and
typo
fixes,
particularly
the
two
noted
there,
which
occurred
multiple
times
next
slide.
H
And
then
there's
changes
from
09
to
the
currently
posted
10
version.
The
l2
tpv3
flow
spec
in
there
was
extended,
and
previously
it
was
good
for
data
messages,
but
it
didn't
really
cover
control
messages,
so
that
involved
one
fairly
small
addition:
sort
of
expanding
the
capabilities
for
that
particular
tunnel
type.
And
the
second
point
here
is
the
various
fields
which
were
added
for
matching
purposes
to
handle
control
messages
and
for
further
editorial
improvements
next
slide.
H
So
what
the
nlri
looks
like,
so
you
have
the
overall
length
and
then
there's
the
tunnel
type.
So
you
know
you
if
you
have
to
have
a
tunnel
type
if
you're
using
this,
it's
only
for
tunnel
traffic
and
it
only
matches
tunnels
of
that
type.
H
There
are
two
flags.
One
indicates
whether
or
not
there's
a
routing
distinguisher
present,
because
you
want
to
handle
a
vpn
case
and
the
other
is
whether
or
not
there's
an
what
is
called
an
inner
flow
spec
so
moving
down.
Then
there's
the
outer
flow
spec
and
that's
matches
an
outer
header,
which
type
is
determined
by
the
affy
for
the
atheist
fee
that
invoked
this
parsing
and
interpretation.
H
It
could
be
extensive
or
could
be
minimal
depending
on
the
kind
of
tunneling
and
then,
if
you
have
indicated
it's
present,
that
you
can
have
an
optional
inner
flow
spec
and
you
have
to
provide
another
affi
down
there
for
that,
because
you
need
to
indicate
whether
you
want
the
inner
flow
spec
to
match,
for
example,
ipv4
or
ipv6
next
slide,
please
so.
Here's
a
simple
example
where
there
actually
isn't
anything
to
match
in
the
tunnel
header
it's
ip
and
ip.
So
you
have
that's
the
outer
and
an
interflow
spec.
H
If
you
wanted
to
match
across
those
things,
you
wouldn't
do
you
you,
you
initially
be
matching,
probably
the
ip
header,
but
if
it
was
in
the
vpn,
you
might
want
to
match
an
initial
l2
header.
Next
exam
slide
bleed.
H
This
is
a
slightly
more
complicated,
vxlan
case.
In
this
case
there
is
the
vxlan
header,
it
can
match
fields
in
there
and
similarly
there's
an
outer
and
inner
flow
specs,
and
in
this
case
the
interflip
would
be
optional.
You
might
want
to
only
match
outer
and
some
fields
in
the
vxlan
header,
like
the
vni
or
something
and
not
match
anything
on
the
inner
header.
H
So
I
believe
that
this
draft
is
ready
for
working
group
last
call
to
see
what
comments
there
are
here
at
this
meeting
and
perhaps
in
over
the
short
period
of
time,
and
maybe
do
one
revision
and
then
do
work
with
last
call.
Perhaps
the
ice
jeff
in
the
queue
I
mean
happy
to
hear
what
he
has
to
say.
J
Hi
kittyrb,
yes,
yes,
jeff!
So
donald
we've
gone
through
a
lot
of
learning
as
part
of
working
through
the
5575
biz
stuff.
You
are
doing
this
as
a
new
affy
safy
pairing.
So
this
is
effectively
ships
in
the
knight
versus
the
other
spec.
You
really
don't
have
any
real
dependencies.
J
As
far
as
that
piece
is
concerned,
the
thing
I
have
to
ask,
though,
is
that
since
you're
sort
of
leveraging
existing
encoding
types,
you
know
in
terms
of
like
the
op
fields
as
an
example,
that
means
that
as
you're
specifying
things
you're
vulnerable
to
one
of
the
interesting
extension
headaches
that
we
found
5575.
J
H
H
Say:
okay,
the
the
this
draft
says
that
for
the
matching,
the
headers,
which
is
the
really
new
you
know
substance
to
be
matched
that
there's
a
separate
registry
and
it's.
I
believe
it
says
that
they
are
all
tlv
format,
so
it
doesn't
say
anything
specific
about
what
to
do
about
unknown
types,
for
example.
J
Possibly,
and
I'm
also
realizing
that
I
was
looking
at
version
8
rather
than
version
10,
where
I
see
you've
actually.
K
I
H
Well,
okay,
I
think
you
know
it's
looking
at
it
from
the
point
of
view
of
extensions
in
the
future.
For
example,
a
new
tunnel
header
type
is
something
useful
to
do.
J
E
Oh,
hey
donald.
I
have
a
quick
question
just
to
see
if
I
understand
what
you
just
said
to
to
jeff.
So
what
you're
doing
is
the
encoding
in
the
nlri
of
the
operators
right
in
the
components
to
match
is
now
tlv-based.
H
Yes,
yeah,
essentially,
the
the
fields
being
matched
are
all
either
like
value
fields
or
bit
fields,
or
something
like
that.
So
the
existing
match
operators
and
way
the
value
to
be
matched
is
encoded
and
the
logic
of
having
multiple
of
those
and
the
ending
and
oring
is
sort
of
all
the
same
but
they're,
I
believe,
all
teals.
H
They
all
have
type
and
length
at
the
beginning,
and
so,
even
though
the
value
in
coding
is
copied
from
earlier
documents
and
they
have
a
it's
a
new
registry
within
types
that
can't
conflict
right.
So.
E
Okay,
so
I
have
a
question
not
for
you,
but
maybe
for
the
chairs.
Well,
we
were
doing
5575
bis
and
the
v6
flow
spec.
C
Yeah
I'll
take
this
so
alvaro.
You've
hit
a
point
that
I
was
gonna
raise
anyway.
Here's
our
challenge
working
group.
This
draft
was
adopted
before
we
got
into
the
understanding
of
how
much
tlvs
are
problematic.
I
was
hoping
that
jeff
had
read
the
most
recent
version.
C
C
What
the
working
group
wants
john-
and
I
specifically
limited
the
first
three
things
to
what
the
operators
told
us,
which
is
5575
bis
v6,
because
the
isgs
strongly
wanted
it,
and
so
did
the
operators
and
the
oid,
because
the
operators
wanted
it.
I
would
love
comments
now.
We
also
can
take
comments.
John,
should
we
take
this
to
the
list
because
of
time
or
shall
we
allow.
A
C
I'd
I'd,
like
some
feedback,
should
we
delay
this
to?
Is
anybody
are
the
opportunities
waiting
for
this
or,
as
I've
announced
it's
time
to
start
v2?
Shall
we
put
this
in
v2
this
document
with
what
donald's
done
starts
to
have
all
the
tlvs?
We
don't
know
if
there's
any
problems,
it's
sort
of
going
toward
that
direction,
feedback
working.
A
J
I'll
early,
three
very
brief
ones,
the
first
one
is:
do
we
one
way,
you're
gonna,
fit
downflow
suspect
as
v2.
That's
an
open
question.
We
we
could
certainly,
I
think,
the
interesting
question
that
drives
that
more
than
you
know
do
we
have
to
do
it.
J
Just
for
your
niceness
of
encoding
is
really
whether
or
not
you
know
use
cases
for
this
draft
are
intended
to
overlap
ever
the
stuff
in
the
existing
flows
back
documents,
because
then
what
you
would
end
up,
having
is
basically
firewall
rules
that
in
one
case,
deals
with
the
tunneled
stuff,
and
then
you
have
a
different
case
of
no
overlapping
with
the
existing
use
cases.
J
If
the
two
are
intended
to
be
mixed
at
some
point
having
them
as
separate
after
saffies
is
a
little
weird
if
it
really
can
live
as
ships
at
night,
even
if
it's
just
temporary
because
of
a
strong
need
for
the
use
case
to
be
deployed,
nothing
stops
somebody
from
shipping.
You
know
basically
this
version
of
the
draft
to
cover
the
use
case,
and
then
we
end
up
with
spec
v2.
We
end
up
in
the
merged
form.
C
Show
of
hands
thing
see
if
we
can
get
some
sense.
H
Can
I
make
a
brief
comment?
I
I
just
wanted
to
say
that
I
think
that
a
working
group
last
call
would
cause
greater
working
group
attention
and
review
of
this
document,
and
that
would
perhaps
yield
something
which
clearly
better
expressed
the
need.
What
the
actual
you
know,
requirements
and
an
adequate
mechanism
would
be.
Certainly
the
the
flowspec
needs,
as
indicated
by
this
draft,
should
be
one
of
the
inputs
to
the
v2
effort.
I
would
think
that
was
my.
C
C
Okay,
donald,
do
you
feel
like
I,
I
any
other
comments
from
other
people.
John.
Do
we
have
people
in
the
mic
queue
we
do
not.
I
think
that
we
can.
A
C
It
will
start
there,
but
I'll
put
some
details
in
the
working
group.
Last
call
regarding
close
back
me
too
and
sounds
good.
Okay,
john.
I
think
donald
anything
else
you'd
like
to
say
about
the
working
group
last
call.
H
Nope,
I'm
in
favor
of
it,
but
other
than
that.
Thank.
L
L
So
after
we
receive
those
comments
and
then
we
update
the
document
and
then
address.
I
think
we
think-
and
we
address
the
those
comments,
so
those
comments
can
be
classified
three
three
groups.
One
group
is
that
we
already
have
configurations
we
can
for
dynamic,
adjuster
traffic.
We
can
do
this
job
through
configurations,
so
why
do
we
need
rpd
for
dynamic
traffic
adjustment?
So
that's
the
one
group
of
comments,
so
another
group
of
comments
is
that
so
in
in
the
older
document,
so
it
looks
like
that
the
rpd
route
is
distributed
through
p2p
or
p2mp.
L
L
So
the
third
group
of
comments
is
about
the
issues
about
failures,
so
when
really
happens
so
what
happens
for
this
kind
of
traffic
adjustments?
L
So
we
address
this
three
group
of
comments
we
already
addressed
this
through
commonly
in
the
document
today.
We
just
briefly
talk
about
the.
What
how
we
address
these
comments.
Next
switch.
L
So
for
for
operational
network,
so
we
already
have
tons
of
configurations
so
in
order
to
adjust
the
traffic
dynamically,
so
we
can
use
the
configurations,
but
if
we
use
configurations
to
dynamically
adjust
the
traffic
so
because
we
already
have
tons
of
existing
relatively
stable
configurations
number
of
nodes
in
the
matter,
for
example,
we
have
tons
of
configurations
on
node
a
and
then
we
have
tons
of
configuration,
node
b
and
so
on.
L
So
in
order
to
adjust
the
traffic
dynamically
as
soon
as
we
want
to
adjust
the
traffic,
then
we
need
put
or
push
some
configurations
to
sum
to
those
some
of
the
loads
in
the
network,
because
this
adjust
of
traffic
is
dynamic,
so
we,
the
frequency,
may
be
sometimes
high
and
then
so.
This
kind
of
configuration
change
and
some
of
the
nodes
of
the
network
will
be
very
sometimes
frequent
and
then
sometimes
maybe
it's
not
that
frequent.
L
So
with
this
kind
of
operation,
so
change
configuration
on
some
of
those
and
then
delete
the
configuration
of
something
nodes
for
dynamic.
Adjust
traffic
will
have
some
issues.
For
example,
this
kind
of
operation
is
very
complex
and
error-prone.
In
addition
to
that,
this
kind
of
dynamic
we
have
a
stable
configuration
and
then
we
have
the
name.
Calculation
keep
changing.
So
this
is
hard
for
for
operator
for
operators
to
maintain
this
kind
of
things
so
with
the
rpd
ross
and
then
this
issues
or
problems
is
well
is
so
is
resolved.
L
So
I
us
so
another
group
of
comments
from
the
logical
is
that
of
people
say
that
this
kind
of
rpd
wrong
distribution
is
a
p2p
and
even
though
they
can
be
a
p2mp,
so
we
just
disk
this
one.
So
we
through
updates
document
with
more
details
and
then
through
this
update.
So
we
can
see
that
rp
raw
distribution
is
p2.
L
Mp
is
about
a
p2p,
so
here
we
show
a
typical
application
scenarios.
So
in
this
network
we
have
a
1s
s1
and
then
we
have
another
two
as
s2
and
s3.
So
here
we
we
have
a
controller
and
that
controller
is
is
connected
to
a
router
reflector.
So
this
rolls
reflector
is
connected
to
all
the
other
nodes.
So
here
we
just
show
the
nodes
a
b
and
c,
so
you
want
to
adjust
traffic
dynamically.
L
L
So
after
each
of
the
routers
receive
these
rpd
routes,
so
it
will
apply
the
policy
included
in
this
rp
route
to
to
to
the
to
the
routers
or
or
according
to
the
peers
or,
for
example,
we
can
apply
those
policies
controlled
by
the
pip
address.
So
if
a
pip
address
is
zero,
then
that
means
we
will
apply
the
policy
to
order
all
the
ps.
So
if
this
p
address
is
a
determined
is
not
zero.
That
means
we
just
apply
that
policy
to
data
to
that
ps.
L
L
So
the
last
of
the
group
issue
is
about
about
failures,
so
so
the
thing
is,
we
can
classify
different
types.
One
type
is
that
the
failure
is
a
because
of
bach,
for
example,
failure.
The
route
is
fair
if
we
cannot
of
a
route
fails
to
install
the
routes
in
the
folding
table,
so
this
is
out
of
our
control.
This
is
the
box,
so
we
need
to
fix
this
bug,
so
this
is
a
fairly
easy
to
qualify.
This
video
is
out
of
of
the
this
document,
so
another
thing
is
that
we
can
have
controller
failure.
L
We
can
have
a
failure
of
illustrations
between
the
controller
and
the
router
reflector.
So
for
these
kind
of
failures,
so
we
can
use
existing
gr,
so
we
can
use
the
basic
jr
so
in
this
case
either
controller
failure
or
session
failure,
and
then
those
of
the
routes
for
use
for
adjustment
traffic
can
stay
there
for
some
time.
So
if
we
use,
we
think
that
this
time
it's
not
a
long
enough,
so
we
can
use
a
long
leaf
restart.
So
in
this
case
we
can
keep
that
route
for
adjusting
traffic
longer.
L
So,
in
what's
the
case,
so
even
so,
we
use
this
kind
of
a
great
gr,
try
to
keep
the
route
for
adjusting
trafficker
get
withdrawn.
So
in
this
case
the
worst
case
is
that,
even
though
this
christmas
doesn't
work
for
this
case,
we
go
back
to
the
original
routes.
That
means
we
try.
We
try
to
use
the
rpv
rules
to
adjust
traffic
to
the
base
of
the
routes
we
think,
but
because
of
a
failure,
those
are
adjust
the
votes
for
adjustments
get
withdrawn.
L
A
A
Yeah,
I
think
I
think
g's
suggestion
is
good
and
we
should
move
on
to
the
next
presenter
and
you
know
they
should
work
on
audio
in
the
meantime
and
we
can
come
back
okay,
so
we're
going
to
switch
we're
going
to
continue
to
the
next
next
talk
and
then
we'll
come
back
once
yeli
has
audio
worked
out.
N
N
Yeah,
so
in
let's
draft
we
mentioned,
I
think,
were
to
refer
to
the
family
of
the
unpassed
telemetry
techniques.
We
include
in
this
terminology
has
the
iom
and
the
alternate
marking
method,
and
we
also
considering
the
iphage
domain.
It
means
that
the
perverse
measurement
domain
so
from
the
security
consideration
size
to
to
avoid
the
I
feed
data
leakage
outside
the
domain.
So
we
need
to
make
sure
that
I
face
the
capsulating
node.
N
That
is
the
tail
nodes
must
remove
the
data
field.
So
so
that's
why
we
extend
to
the
bgp
protocol
to
advertise
the
iphone
the
capsulation
node
capability
to
the
head,
node,
so
taking
less
extension
to
bgp
protocol.
The
head,
node
can
collect
the
information
and
to
know
whether
the
tail
node
can
support
the
specified
effect
capability
before
insert
the
ipad
command
into
the
traffic
packet.
N
So
from
this
motivation,
we
we
defined
two
options
in:
let's
drop,
to
make
the
extension
to
b2p.
The
first
of
all
is
the
extension
to
ipv6
as
v6
and
ipv
4
address
specific,
extended
community,
and
the
second
option
is
to
extend
to
the
bgp
next
top
capability
yeah
from
yes.
Next,
thanks
so
from
first
of
all,
we
we
need
to
define
the
f8
capability,
what
what
is
the
capability,
so
here
we
mentioned
the
format
field
we
defined
in
less
dot.
Here
we
see
this.
This
is
a
16
bit
bitmap
field.
N
It
can
include
the
five
options
a
bit
to
indicate
what
kind
or
which
kind
of
the
performance
management
method
can
be
supported
at
the
the
tail
nodes
it
includes
ion
and
alternate
marking
method.
N
Next,
thanks
next
slide.
Yes,
so
here
is
the
option
one.
It
is
an
extension
to
bdp
extended
community.
N
Here
we
are
considering
to
extend
to
the
ipv6
and
the
v4
address
specific,
I
think
extended
community
we're
considering
this
is
the
a
transitive
optional
extended
community.
So
we
can
use
this
to
to
notify
the
the
iphat's
capability
to
observe
the
tail
node
to
its
partner.
N
I
mean
the
effects
encapsulation
node,
so
here
from
this
two
figure,
we
can
see
that
the
format
and
in
this
format
the
optional
ipv4
address
and
and
the
v6
address-
is
the
address
of
the
iphas
encapsulation
node
yeah
next
piece,
please
so
yeah
that
this
is
the
option.
Two
is
it
extension
to
the
bgp
next
top
capability.
N
So,
as
we
see,
the
working
groups
are
draft
defined
bgp
network
capability
is
a
a
non-traditive
bdp
attribute,
so
we
can
consider
use
this
in
in
the
intro
domain
so
to
notify
the
tail
nodes
capability
to
the
head
nodes.
N
A
Thanks
any
many
comments.
A
I
I
It
is
introduced
in
the
sr
policy
architecture
draft
that
candidate
power
can
be
used
for
path,
protection
and
and
sr
policy
allows
for
multiple
kennedy
powers
and
only
one
hectic
candidate
parts
can
be
provisioned
in
the
forwarding
plan.
At
the
same
time,
so
other
lower
preference
can
in
the
past
may
be
used
as
a
backup
house
when
distributing
sr
policies
using
pdp.
I
Each
candida
path
is
carrying
an
mli
so
far.
There
also
no
mechanism
to
carry
the
protection
relationship
from
kennedy
park
in
bgp
advertisement
and,
of
course,
we
can
do
it
by
local
configuration
and
backup
candidate
provides
protection.
Only
when
the
segment
lists
in
the
active
canada
house
are
invalid.
I
I
If
you
want
to
prove
for
protect
second
laser
one,
so
flows
can
still
be
load
balanced
between
second
laser
two
and
the
back
up
path.
After
seven
minutes,
long
field
using
canadian
parts
for
protection
can
not
achieve
that
goal,
and
this
document
proposes
extensions
of
vgp
in
order
to
provide
pass
protection,
use
segment
lists
when
delivering
as
a
policy.
I
Settlement
list
can
be
used
solely
or
combined
with
kennedy
pass
together
for
pass.
Protection
on
this
figure
gives
an
example.
The
harriet
node
has
received.
Two
candidate
parts
belong
to
the
cmsr
policy,
and
cp1
has
the
higher
preference,
so
cp1
is
chosen
as
a
primary
pass
and
in
cp
1
list.
3
is
a
backup
list,
so
it
will
not
be
enabled
on
the
data
plane
at
first
after
this
one
fails.
The
3
will
take
place
if
list
2,
and
this
3
are
both
invalid.
I
Here
are
the
bgp
extensions
for
sr
policy,
proposing
this
draft
and
the
b
flag
in
segment
list.
Sub-Tree
indicates
the
segment
list
acts
as
a
pure
backup
part
in
the
kennedy
pass,
and
this
identifier
trv
is
used
to
identify
the
corresponding
segment
list
and
it
contains
the
optional
sub
theory
list
protection
theory
which
carries
the
protection
relationship
of
segmentations.
I
I
And
in
the
tlsp
distribution
draft
they
could
describe
a
mechanism
to
collect
the
sr,
the
policy
information
that
is
locally
available
in
the
node
and
advertise
it
into
pgpos
updates
and
it
it
includes
sr
candidate,
pass
state
cov
and
has
a
settlement
list
to
trv
and
the
sab
flag
who
are
originally
defining.
Can
we
deposit
a
tree?
Well,
the
extracting
the
case.
The
candida
parts
is
an
administrative,
sharp
state
and
pay
flag
in
the
case.
Can
it
pass
in
the
active
part
and
b
flat
in
the
case
of
kenya?
I
Park
is
a
backup
and
two
new
flat.
Two
new
flags
are
introduced
in
this
draft
in
sr
segment
list,
tlv
to
offer
more
details
of
the
settlement
list,
states
and
the
s
flat
and
the
b
flat
as
a
similar
meaning
and
the
s
flag
indicates
a
second
list
using
the
administrative
chart
state
and
the
b
flag
indicates.
The
settlement
list
is
a
backup.
Part
can
be
next
like
please
and
anything
will
pass
feedback.
Some
comments.
F
F
Thanks
for
the
update
of
your
draft,
what
I
would
suggest
is
some
of
the
proposals
here,
like
you
know,
having
a
primary
and
backup
semantic
within
segment
list
of
a
candidate
part.
I
mean
this,
isn't
something
that
is
covered
by
the
base
specifications
in
spring
working
group.
F
Also,
this
notion
of
you
know
primary
and
backup
candidate
path.
That
is
something
which
is
covered
to
some
extent,
but
then
there
is
also
you
know
the
way
the
candidate
part
selection
happens.
F
A
K
Oh
good,
okay,
so
here
we
want
to
propose
a
new
path
attribute
in
the
bgp.
Mri
called
app
metadata
are
the
purposes
for
5g
edge
computing
service
next
page,
please.
K
Okay,
so
the
purpose
is
to
for
the
5g
edge
computing,
be
able
to
propagate
the
running
status,
including
environment,
including
site,
prefix,
site
preference
or
capacity
into
the
ingress
router
for
them
to
make
intelligent
decisions
to
achieve
optimal
performance
and
the
user
experience
next
page.
K
So
a
little
bit
background,
5g
edge
computing
is
a
project
in
the
3gpp
sa2,
and
this
is
defined
in
the
tr23
748
or
the
release
17.
They
have
identified
many
use
cases,
for
example,
drone
communication
with
controller.
K
They
require
back-end
servers
to
be
very
close
to
the
device
and
also
they
require
multiple
servers
for
the
same
applications.
So
you
could
have
5g
sites
and
each
of
the
cell
tower
to
to
have
this
back-end
server
hosted
and
they
have
virtual
interactive
conference.
All
those
use
cases
being
identified.
There
all
have
the
requirement
of
the
short
delay.
K
So
one
of
the
characteristics
of
5g
system
is
the
size
are
very
close
in
proximity.
So
you
can
have
one
side
like
you:
have
a
bunch
of
ues
user
device
anchored
into
psa
psa
means
packet,
section
anchor
and
they
go
to
the
local
data
network
and
you
could
have
another
psa
too
in
very
close
proximity.
So
for
the
server
back-end
server
you
could
have
multiple
copy
of
them
very
close
nearby.
K
K
So
the
the
benefit
of
anycast
is
really
for
network
to
expose
to
utilize
or
leverage
the
network
routing
layer
to
help
application
to
achieve
better
performance
and
to
eliminate
the
single
point
of
failure
of
the
local
dns
resolvers
or
the
application.
Low
server
load,
balancers
and
also
many
client
in
the
fixed
network
or
in
the
mobile
or
ue,
tend
to
use
their
cache
ip
addresses
for
extended
period
of
time.
K
So,
even
if
you
have
local
dns
resolver
in
each
of
the
local
data
network,
you
when
they
move
to
a
new
location,
they
may
not
resolve
to
find
a
new
ip
address,
so
the
benefits
are
great,
but
they're
also
bring
a
bunch
of
issues.
One
of
the
key
issues
is
when
all
those
servers
are
very
close
in
proximity.
K
The
routing
distance
routing
cost
can
be
very
small
and
is
smaller
than
other
factors.
For
example,
in
this
example,
you
can
have
eas
eas
meaning
edge
computing
application
server,
one
in
local
data
network,
one
has
high
capacity
versus
eas2
in
ldn2,
is
over
over
utilized.
K
So
when
the
ue
moved
to
anchor
to
the
psa2,
the
performance
overall
performance
will
be
better
if
they
are
still
served
by
their
original
es1.
So
the
many
factors
are
affecting
where
the
routing
is
another
issue
that
quite
different
bring
in
by
this
edge
computing
is
from
the
psa2
the
package
session
anchor
2.
K
There
could
be
many
ues
already
anchored
there
and
they
using
their
local
algorithm
to
choose
the
the
right
edge
server,
maybe
eas2,
but
when
the
ue
one
move
from
the
anchor
ps
psa1
to
psa2,
the
better
service
will
be
provided
by
es2,
so
same
destination
same
address,
the
performance
can
be
based
on
different
source
can
be,
can
be
different.
A
M
I'm
just
wondering
if
it's
an
anycast
address,
how
do
you
buy?
How
do
you
find
an
a
ue
to
a
server
because
you
don't
want
it
to
assuming
their
their
state
associated
with
the
ue.
K
Okay,
okay,
so
in
in
today,
especially
if
you
look
at
ipv6
right,
they
have
a
flow
label.
So
many
today's
routers
support
putting
all
the
flows
all
the
packing
within
one
flow
into
one
path.
Okay,
that's
one
criteria
later
on.
I
can
explain
some
of
the
criteria
for
them
put
into
the
ingress
router
so
that
they
can
guarantee
that
a
packet
belonging
to
one
flow
always
anchor
into
one
particular
instance
of
anycast
server.
M
A
O
Okay,
good,
I
don't
know
linda
if
it
helps.
I
see
that
you're
I
mean.
I
see
one
slide
that
talks
about
within
the
market.
I
see
another
slide
that
talks
across
markets
and
I
know
you're
trying
to
kind
of
represent
the
ip
network,
but
I
don't
know
if
it
helps.
If
you
can
draw
out.
You
know
the
du
cu
upf,
because
you
know
in
the
old
days
that
was
all
you
know,
backhaul
now
between
frontal
mental
and
backhaul.
K
John,
if
you
can
bring
up
the
previous
page
so
in
this
network,
obviously
from
the
base
station
e
note
b
to
the
psa,
that's
within
5g
system,
so
they
have
ip
network
as
well.
There's
a
draft
in
the
dmn
on
the
tn
aware,
mobility
about
network
within
the
5g.
They
have
net
ip
network
here.
I'm
talking
about
a
local
data
network
after
the
upf,
so
upf
and
psa
is
psa,
is
a
function
of
the
upf
user.
K
User
user
packet
function
right
upf,
so
the
ldn
local
network
data
network
is
completely
ip
network
outside
the
the
5g
is
serving
the
5g
system.
K
Okay,
so
maybe
later
I
can
refine
the
the
the
description,
maybe
in
the
draft.
Hopefully,
people
can
get
more
comments.
K
Okay,
so
then,
so
this
page
is
about
in
the
5g
edge
computing
service
to
select
a
particular
edge
server.
Traditionally,
anycast
is
purely
based
on
the
network.
Routing
cost
right,
but
in
the
5g
edge
computing
environment,
for
example,
s1
here,
and
they
are
in
three
different
locations,
because
three
different
local
network
and
the
network
routing
distance,
maybe
there's
difference
the
round-trip
time,
maybe
a
little
bit
different,
but
there's
other
factors.
For
example,
s1
could
be
a
bigger
capacity.
K
L
s,
one
l
d,
one
could
be
bigger
capacity.
I
could
have
multiple
servers
behind
a
load
balancer
than
the
s1
in
the
ld3.
K
K
There
could
be
that
for
particular
ue1
that
he
actually
initially
anchored
to
psa1
upf1
and
go
to
the
ldn1
s1
when
he
moved
to
the
side
b,
which
is
maybe
very
close
to
each
other.
The
capacity
over
taking
the
network
delay
so
the
quite
a
few
different
factors
for
the
ingress
router
to
consider
to
choose
optimal
optimal
of
any
cast
location.
K
That's
why
we
want
to
introduce
some
matrix
for
the
egress
router
r1
r3
r2,
to
propagate
it,
to
the
ingress
router
which
make
decision
importing
next
page.
Please.
K
Okay,
so
here
is
why
we
need
this
mat
application
metadata.
So
this
is
a
new
path
attributes
which
include
load
measurement,
meaning
for
the
each
of
the
egress
router,
which
have
the
server
application
servers
directly
attached
be
able
to
do
some
measurement
on
the
traffic
flow
to
and
from
the
server.
There
is
a
capacity
index.
K
This
capacity
index
can
be
pre-configured
or
could
be
learned
based
on
historic
data,
and
there
is
a
site
preference,
so
the
site
preference
can
be
dynamic
based
on
who
is
accessing
it
depending
on
different
ue.
The
preference
could
be
different
so
with
all
those
combinations
added
together,
the
ingress
router
can
make
intelligent
decision
in
the
draft
there's
a.
We
give
an
example
algorithm
how
the
ingress,
router
utilize
different
attributes
to
compute
the
index
to
choose
which
side
to
use,
there's
also
other
factors
to
be
considered
in
the
rtg.
K
So
basically,
that
drive
is
about
within
the
5g
that
gdp
tunnel,
they
use
udp
port
range
to
represent
different
priority
or
different
slicing
of
the
network,
and
those
information
can
be
passed
through
the
5g
network
exposure
function
to
the
local
ip
network
and
that
information
can
also
be
carried
by
the
pgp's
app
metadata
tlb
to
pass
to
relevant
routers
next
page.
Please.
K
Here
is
the
load
measurement
as
the
router
itself.
We
most
likely
applications
are
encrypted.
They
don't
give
us
information
about
the
internal
logic
and
from
the
plumbing
side
we
can
only
see
the
packets
going
into
the
router
going
to
the
server
and
coming
from
the
server
and
from
historic
data.
The
an
analytic
tool
will
be
able
to
measure
like
like
this
particular
hours.
K
K
Suppose
the
router
egress
router
have
the
information
so
for
load
measurement.
So
far
we
defined
two
types
of
load
measurement.
One
is
the
raw
measurement.
The
raw
measurement
can
be
useful
for
analytic
tool.
Like
suppose,
there
is
a
little
tool
attached
to
the
raw
reflector
and
that
need
the
raw
data
for
future
prediction.
K
Another
matrix
to
be
propagated
is
aggregated
index
so
that
suppose
all
the
routers
belonging
to
belong
to
same
provider.
They
can
have
the
same
algorithm,
for
example,
here
kind
of
waited
about
all
those
different
measurements,
they've
added
weight
together
to
come
up
with
the
aggregated
load
index
and
this
index
being
propagated
to
the
ingress
router
next
page.
Please.
A
A
K
K
Application
server
the
computing
services
can
expose
the
internal
logic
to
the
network
and
having
the
routers
in
the
network
to
be
aware
of
the
computing
resource
being
utilized
by
different
app
server
and
be
able
to
forward
it
appropriately.
So
those
kind
of
information
can
also
be
carried
by
those
app
metadata
path,
attributes.
Of
course,
they
may
introduce
some
new
subtleties
to
indicate
the
detailed
attributes
exposed
by
the
app
server.
K
K
Application
servers
and
that
is
also
can
be
configured
and
can
be
had,
can
have
the
configured
algorithm
to
calculate
the
prefix
preference
index
in
the
okay
next
page.
Please.
M
I
mean
it
wouldn't
be
the
only
way
to
implement
it,
but
I
think
you
need
to
specify
how
this
forwarding
plane,
like
like
a
reference
model
for
this
forwarding
plane
that
you're
envisioning,
you
can't
just
wave
your
hand
and
say
ip6
has
a
ipv6
says
a
flow
label,
so
it,
and
at
least
at
least
in
one
of
these
one
of
these
drafts,
with
all
these
metrics,
you
need
to
have
that,
with
the
all
the
anycast
reachable
anycast
destinations
and
at
least
one
reference
on
how
you
would
envision
this
working,
because
I
don't
think
anything
like
this
exists
today.
K
Okay,
I
will
add
the
section
on
that.
You
know
what
I'm
talking
about
right
here.
Support
flow
base,
forwarding.
A
You
thank
you
and
we
have
a
couple
more
in
the
queue,
so
you
want
to
keep
taking
those
boris.
Please
go
ahead.
B
Thank
you,
john
linda
one
question:
I'm
a
bit
worried
about
is
bgp
right,
like
transport
or
tool
for
sending
clothes
measurement
information,
because
information
about
particular
load
of
this
aggress
node
will
be
delivered
with
delay
right
handling
delay.
So
it
will
be
information
about
load
in
the
past,
and
my
concern
is
about
how
actual
this
information
will
be
to
make
this
change.
B
K
That's
a
good
question
so
here
we're
not
talking
about
transit
measurement,
we're
talking
about
historic
measurement,
so
you
are
talking
about
like,
for
example,
last
24
hours,
measurement
versus
last,
one
hour,
average
and
or
last
one
month
average.
So
it's
not
about
very
transit.
So
the
goal
is
really
to
estimate
the
load
measurement
compared
to
the
historic
data.
K
So
here
I'm
just
not
giving
the
specifics
on
how
actual
measurement
could
be
done.
It
could
be
that,
like
in
the
compute
first
network,
the
server
themselves
being
able
to
expose
that
they
could
use
other
information,
maybe
genevieve
header,
to
be
able
to
expose
the
internal
requirement
a
desire.
So
that
is
not
specified
here
here.
K
I'm
just
saying
that
when
those
information
becomes
available
need
to
be
propagated,
I'll,
take
aces
comment
and
give
a
explanation,
just
assuming
certain
like
a
reference
design
like
how
this
the
flow
basically
will
work
in
the
next
revision.
O
I'm
guessing
you
can
hear
me,
this
isn't
just
semantics:
it's
not
technical,
but
you
know
you
started
with
saying
edge
compute
and
I
see
multiple
ip
networks.
You
know
you
know
you
get
to
think
about
what
qualifies
as
edge.
You
know
if
you
go
across
multiple
isps
and
your
way
across
the
line.
Is
that
really
an
edge
compute?
So
I
think
it's
semantics,
I
I
know
I
looked
at
it
some
pages.
K
All
right,
let's
continue.
Okay,
so
in
terms
of
propagation
of
the
app
metadata
we
could
use
the
ifc
4684,
the
rt
constraint.
Distribution
only
distribute
the
information
to
the
relevant
routers,
because
if
you
look
at
those
services
like
edge
servers,
they
are
not
everywhere
and
also
that
not
every
ingress
or
psa
would
have
the
user
device
interested
in
those
services.
K
So
the
distribution
doesn't
have
to
be
broadcast
to
every
router,
since
there
are
many
more
much
more
numbers
of
edge
servers,
application
servers
than
like
rt
constraint
being
meant
for
for
the
routers
we
could.
Another
alternative
is
to
create
this
app
server
bug
group,
so
this
group
can
be
statically
configured
or
can
be
each
ingress.
Router
can
ask
for
the
network
controller,
who
are
the
ones
interested
in
this
particular
service,
also
need
a
time
to
live,
because
for
any
service.
K
The
the
time,
if
there's
nobody
inside
a
anchor
to
this
psa,
is
interested
in
that
service,
then
that
ingress
router
to
the
local
network
that
doesn't
have
to
be
receiving
the
information
about
the
specific
fm
app
server
s1.
So
those
are
just
about
the
scope
of
the
propagation.
K
So
this
is
referring
to
this
particular
specific
requirement
by
the
switchy
edge
computing.
So
for
app
server,
for
example,
app.net
right
app.net
has
servers
located
attached
to
r1,
r2
and
r3.
K
K
I
want
the
service
to
go
to
e2
or
e3,
so
in
networking
we
have
done
a
lot
of
protection
right.
This
is,
can
be
achieved
by
assigning
multiple
addresses
into
one
app
server
we
can
achieve.
We
call
soft
anchoring
because
it's
not
specifically
anchored
to
our
r1
or
this
app
server.
The
way
to
achieve
that
is
we
create
for
this.
App.Net
will
create
a
group
of
anycast
addresses
g4,
being
the
address
which
not
relevant
to
the
location
is
not
location.
Preferred
l1,
address
is
preferred
to
be
anchored
to
r1.
K
L2
address
is
preferred
to
be
anchored
to
r2.
L3
address
is
preferred
to
be
anchored
into
r3,
so
with
different
cost,
and
the
network
can
be
able
to
consider
all
the
other
costs
like
network
delay.
There
could
be
site
capacity
index,
some
other
information,
all
consolidated
together
to
make
the
intelligence
decision
and
when
the
like,
for
example,
if
it's
anchored
to
r1
if
something
fail,
and
then
they
will
be
equally
distributed
by
r2
or
r3,
depending
on
the
other
factors.
K
So
that's
I
think
the
network,
the
ip
layer
can
provide
a
very
elegant
solution
than
the
dns
solution.
K
Okay,
I
think
that's
it.
The
background
information
is
about
how
do
we
just
example
algorithm
in
choosing
appropriate
egress
router
for
any
cast
location
that
has
more
discussion
in
the
draft,
so
just
the
information
here
I
wish
we
had
more
discussion
on
the
mentalist
or
from
people
here.
Thank.
P
P
K
We
don't
expect
to
be
very
dynamic,
we
expect
to
be
hours
or
days.
Those
are
the
average
that
that's
that's
something
we
expect
or
better.
If
the
this
provider
actually
owns
those
applications,
then
they
will
be
able
to
give
the
information
directly
and
that
will
be
more.
K
Okay,
so
so,
if
you
look
at,
there
was
a
talk
at
the
nanak
a
couple
of
land
ups
ago
they
talked
about
using
any
cash
to
provide
for
all
their
services.
They
talk
about
like
they
can
change
the
cost.
They
can
change
the
peering
policy,
but
they're
talking
about
in
terms
of
month.
The
traffic
pattern
can
change.
So
that's
with
the
manual
intervention.
K
So
with
this
approach,
the
egress
router
dynamically
measure,
the
the
packets
and
the
adjustment
can
be
in
hours
or
minutes
or
days,
much
faster
than
menu,
reconfiguring
the
cost
and
or
reconfiguring
the
peering
to
better
balance.
The
the
load
to
distribution
to
the
anycast
servers.
Q
Okay,
I'm
still
unclear
about
to
keep
walking.
Could
you
clarify
who
is
taking
the
decision?
Is
it
ingress
router
or
do
you
have
a
kind
of
intelligent
controller
which
is
pushing
to
the
ingress
via
appropriate
heart?
What
is
your
decision
model
here.
K
Q
Yeah
yeah,
but
this
is
bgp.
You
cannot
use
your
own
algorithm.
You
have
to
be
compliant
with
the
existing
bgp
decision
processor.
Of
course
you
can
specify
a
new
standard
which
is
taking
into
account
additional
parameters
somewhere
in
the
existing
decision
process,
but
you
cannot
simply
do
something
else.
K
Well,
wait:
wait!
Let's,
let's
go
to
the
next
page:
let's
go
to
the
maybe
second
third
page,
showing
that
the
network
structure
the
first
page,
maybe.
K
Oh,
oh,
okay,
yeah
yeah,
this
page,
so
the
the
goal
of
this
bgp
is
to
distribute
the
information
once
the
information
is
distributed
to
the
ingress
router
here
and
today
he
used
bgp
to
choose
appropriate
egress
router,
that's
all
true,
but
in
this
5gh
computing
environment,
the
the
ingress
router
is
part
of
the
up,
upf
or
psa
passion
packet
session
anchor,
and
he
will
not
only
just
use
the
network
routing
as
the
only
criteria
to
choose
the
egress
router.
He
has
to
consider
other
factors
because
different.
Q
I
completely
agree
with
you
linda.
My
point
is
just
because
you
are
using
bgp,
you
have
to
comply
with
bgp,
which
means
that
you
cannot
simply
override
the
current
decision
process.
You
can
insert
something
into
the
existing
decision
process,
but
you
cannot
bypass
it
completely.
Otherwise,
you
become,
you
have
a
non-compliant
bgp
implementation
and
if,
if
it's
the
way,
you
want
to
do
simply
don't
use
bgp
and
and
and
write
your
own
protocol.
K
That
could
be
another
way
to
do
it,
but
the
problem
with
that
way
we
have
because
in
the
draft
we
did
document
that
way.
Okay,
so
the
problem
with
that
way
is
first
of
all,
then
all
the
algorithm,
all
the
egress
router,
has
to
be
consistent.
K
In
addition
to
this
cost
matrix
from
r1,
it
may
need
other
factors
to
choose,
because,
for
example,
in
this
our,
for
example,
let's
just
talk
about
the
router
b
right,
but
rather
b
when
he
has
the
ue
traffic
coming
to
s1.
If
it's
original
ue,
he
would
choose
the
s1
closest
to
him,
based
on
the
routing
distance
or
other
conflict
matrix.
But
there's
when
there's
a
ue1
coming
from
5g
side
a
re-anchored
to
psa2,
then
this
particular
flow
need
to
go
to
prefer
to
stick
to
the
original
server.
K
Okay,
so
based
on
the
source,
he
may
need
to
forward
it
to
a
different
server
and
maybe
using
a
tunneling
or
maybe
use
the
sr
technology
to
forward
to
send
it
to
the
egress
r1.
So
the
decision
point
should
be
considered
that
that
not
only
just
the
matrix
themselves,
the
the
computer
cost
the
other
factors
to
be
considered.
Q
O
Much
yeah,
I
heard
the
comment
about
hours
linda.
I
wouldn't
make
a
blanket.
I
wouldn't
make
a
blanket
say
but
about
hours.
Think
about
you
know:
5g
is
not
one
use
case
and
you've
got
consumer,
you
have
enterprise
and
you
have
critical
services.
You
have
some
other
stuff.
So
if
don't
build
your
solution
out
that
the
you
know
the
measurement
is
going
to
be
in
hours
because
in
some
use
cases
that
won't
be
helpful.
So
just
keep
that
in
mind.
K
K
K
Okay,
next
one,
so
this
is
about
sd1
totally
different,
subject:
okay,
so
this
is
about
sql
edge
discovery
using
bgp
next
page.
Please.
K
K
We
want
to
have
a
new
tunnel
type,
sd1,
hybrid
or
other
existing
tunnel
types
and
we
color
it
with
a
specific
color
extender
community
and
then
the
update
2
for
the
node
will
have
the
tunnel
egress
endpoint
to
describe
which
endpoint,
which
port
this
tunnel
ends
terminate
and
we'll
have
the
port
subtly,
which
include
the
isp
information
for
this
particular
one
port
like
whether
it's
from
company,
a
or
company
b,
would
include
geolocation
of
this
node.
Just
assume
that,
when
sd1
deployment
they
can
be
far
apart
in
different
countries
or
different
states.
K
The
lisp
has
this
septual
v
geo
location,
which
is
can
be
very
useful
to
be
included
and
also
optionally,
to
include
all
the
ipsec
sub
tods
episode.
Some
theory
can
be
tricky
because
episode
security
associations
are
pairwise,
meaning
every
node
between
two
every
node.
They
have
different
keys,
so
the
the
attributes,
as
defined
in
the
secure
evpn
you
can
see
is
there
are
many,
of
course
they
can
be
included,
but
also
we
could
include
security
essay
identifiers
which
is
pre-configured
as
well.
K
Next
page,
so
here
is
the
just
illustration
of
the
recursive
lookup,
so
you
have
this
example:
cpe2
has
client
routes,
10.
20.,
something
3.1.1x,
so
for
the
prefix,
10.1.1x
and
20.1.1x.
K
Their
next
hub
is
222,
which
is
cp2,
and
they
are
colored
with
red,
and
it
shows
that
they
are
hybrid,
meaning
that
those
rounds
can
be
carried
by
l3
vpn
pass
terminated
at
the
cpe2
and
also
being
terminated
like
we
have
a
one
port
provided
by
isp1,
192
port
and
another
port
provided
by
the
isp2,
or
you
could
be
terminated
by
the
loopback
address
ipsec
terminated
at
the
loopback
address,
so
either
of
them
will
be
fine,
but
here
we
don't
have
to
specify
that
next
page.
K
Here
is
update,
2,
which
describes
the
detailed
attributes.
K
So
one
way
to
do
it
actually,
with
this
present
at
the
bath
yesterday,
we're
just
using
the
tunneling
attributes
with
the
new
tunnel
type
sd1
hybrid,
which
can
include
all
the
needed
information,
and
you
will
have
the
color.
You
will
have
the
detailed
endpoint
subtle.
You
will
have
the
ip
sub
tovs
or
ipsec
sa
ids.
K
That's
that's
one
way
to
do
it,
but
more
optimized
way
we'll
be
able
to
is
to
create
a
new
savvy
sd17,
which
has
the
color
which
are
applicable
to
all
the
tunnel
attributes
carried
by
this
update
just
make
the
update
more
compact.
K
K
You
can
use
this
tunnel,
you
can
use
the
color
subtly
to
further
identify
the
specific
tunnel.
K
Next
page,
so
this
is
for
the
sd1
hybrid,
hyper,
s1
hybrid
tunnel
type
you
can
here
are
the
introdu.
You
can
include
multiple
underlay
tunnels
included
in
this.
You
can
have
a
list
of
episode
essays.
K
You
can
have
all
those
essay
terminated
at
one
endpoint,
endpoint,
egress,
endpoint,
subtle
and
all
those
ports.
All
those
ipsec
essays
share
the
common
port
information
next
page.
Please.
K
K
K
So
with
the
sd-wan
survey,
just
to
make
the
implementation
easier
when
the
receiver
received
the
update,
the
color
hd1
color
will
be
applicable
to
all
the
paths.
All
the
tunnels
attached
in
this
update,
just
like
sr's
color
and
here
here
are
the
detailed
information
underneath
the
hybrid
sd1
tunnel
type
next
page
for
the
savvy
sd1
sappy,
we'll
have
two
two
types:
one
is
assuming
that
sd1
deployment
is
managed
by
one
single
company
or
all
their
locators
can
be
represented
by
a
local,
significant
identifier.
K
Another
type
is
for
a
large
deployment
where
you
would
require
the
geo
geolocation
sub-glv
to
be
included
to
uniquely
identify
the
location.
The
geolocations
sub
tov
is
from
the
lisp
geolocation
draft.
You
have
a
local
id
port
id
like
suppose
that
you
may
have
a
group
of
cpes
there.
They
may
have
a
local
significant
number
to
represent
different
port
number,
so
that's
has
a
local
id
and
then
you
have
a
coloring
which
represents
the
common
properties
shared
by
all
the
tunnel
attributes
next
page,
please.
K
A
A
Linda,
thank
you
seeing
the
queue
empty.
I
think
that
it's
time
for
us
to
call
it
a
night
slash
morning
slash
afternoon.