►
From YouTube: IETF113-RTGWG-20220321-1330
Description
RTGWG meeting session at IETF113
2022/03/21 1330
https://datatracker.ietf.org/meeting/113/proceedings/
B
It's
2
30
local
time.
We
intend
to
start
on
time
a
very
busy
agenda.
So
please
take
your
places.
Welcome
to
vienna.
I
cannot
even
convey
how
happy
I
am
to
see
I'll
hear
all
10
of
you
at
least
so
welcome
to
idea,
113,
routing
working
group
and
we'll
start
with
meeting.
B
B
Let's
review
our
agenda
quickly.
There
are
more
explanation
on
the
wiki,
so
I'll,
be
very
quick.
We'll
have
young
for
qos
thanks
for
authors.
We
are
pretty
much
ready
for
working
with
plus
call
last
reviews.
Apn
will
update
us
with
all
the
progress
we've
made
over
the
last
couple
of
eight
years.
We've
got
number
of
research
topics
a
lot
of
interesting
new
work,
as
well
as
update
on
rfc
5798,
thanks
ac
for
taking
it
up.
B
We
don't
have
any
rc's
since
112.,
we've
recently
adopted
point
to
multiple
and
bfd
for
vrp
working
document.
The
qs
model,
as
I
said,
is
getting
pretty
much
ready
for
working.
What's
called
reebok
standard
as
well.
Bgp
peak
is
pending
ad
review.
B
It
is
here
too,
to
remember
so
thanks
for
stuart
bryant
for
reviewing
tilfa
draft
there's
still
a
couple
of
reviews
that
needs
to
be
addressed
by
the
authors.
Atnbgp
has
reviewed
couple
of
by
a
couple
of
people.
We
need
more
reviews
here
and
authors
of
the
service.
Six
egress
protection
draft
have
requested
working
group
plus
call,
so
we
are
about
to
start
the
process
and
please
use
our
wiki
to
get
more
information
about
progress
of
the
drafts
about
work.
D
Okay,
so
you
will
be
moving
the
slides
for
me
right.
C
You
I
can
do
it
or
you
can,
if
you
prefer
to
do
it
yourself,
it's
also.
Okay,
you
can
do
click.
The
share,
preloaded,
slides.
E
D
D
D
We
have
improved
the
language
and
explanations
and
we
have
had
a
lot
of
references
as
well
and
in
addition,
we
were
facing
some
warning
draft
warnings.
We
have
taken
care
of
those
and
based
on
those
modifications,
we
have
come
up
with
version
7
of
the
draft
and
we
have
published
it
next
slide.
Please.
D
All
right,
so,
if
we
are
looking
to
randomly
detect
configuration,
it's
something
which
fall
under
algorithmic
drop
and
drop,
algorithm
drop
algorithm
is
appended
to
the
queue
configuration
now.
The
queue
can
be
configured
in
line
versus
a
queue
can
be
configured
as
a
template,
so
so,
under
the
queue
we
have
drop
algorithm
and
under
the
drop
algorithm,
we
have
case
statement
for
randomly
detect
or
weighted
randomly
detect.
D
Now,
if
we
talk
about
randomly
detected
configurations,
we
have
a
minimum
threshold
value
and
maximum
threshold
value
and
there
are
corresponding
units
to
it,
so
the
units
could
be
in
bytes
or
in
time
like
millisecond
or
it
could
be
in
percentage
and
there
is
a
configuration
for
weight
now.
What
is
weight
is
a
decay
factor
in
calculating
the
average
queue
size
now.
Weight
value
is
two's
exponent.
D
So,
for
example,
if
somebody
configure
a
weight
value
of
2,
then
2
raised
to
power.
2
become
4,
and
that
means
the
instantaneous
value
of
the
queue
will
account
for
25
and
the
previous
average
queue
size
will
account
for
25,
75
and
so
and
so
forth.
It
reflect
or
effect
the
the
randomly
detect
algorithm
functionality.
Accordingly,
now
we
also
have
provider
configuration
for
max
probability
value,
so
it
is
the
probability
of
dropping
a
packet
at
the
max
threshold
value.
D
So
also
you
know,
if
you
look
into
randomly
detect
configuration,
we
have
allowed
the
configuration
for
ecn,
enabled
that
is
explicit
congestion
notification
and
what
does
that
mean
is
instead
of
dropping
the
packet,
if
you
find
that
the
packet
need
to
be
dropped?
So
if
the
ecn
is
enabled-
and
the
packet
has
ect
bit
enabled,
then,
instead
of
dropping
the
packet,
it
will
be
marked,
the
congestion
experience
bit
will
be
marked
and
it
will
not,
it
will
be
sent.
D
All
right
so
so
vt
red
is
very,
very
similar
to
randomly
detect,
except
that
we
have
multiple
profiles
per
queue,
and
that
means
every
single
profile
represents
one
color
of
traffic.
So,
for
example,
if
we
have
a
dhcp
value
of
af41,
we
can
configure
that
as
a
profile
and
which
will
have
its
own
minimum
value
and
maximum
value
and
corresponding
you
know
probability
value
and
weight
value,
and
so-
and
you
know
similarly,
we
can
have
a
dhcp
value,
af,
42,
f43
or
af21
as
separate
profiles
under
the
same
queue
next
slide.
Please.
D
All
right,
so
as
next
step
we
have
got,
you
know
a
lot
of
comments
to
be
taken.
Care
of.
We
have
already
worked
on
quite
a
few
so
far,
and
we
are
working
further
to
address
that.
D
Also,
you
know,
while
working
on
the
draft,
we
actually
had
added
a
lot
of
features
to
the
extent
that
you
know
we
have.
D
You
know
if
feature
for
a
lot
of
actions
which
we
thought
that
some
vendor
may
support
and
some
vendor
may
not
support,
but
eventually
we
found
that
you
know
it
is
causing
too
many
features
to
be
there
and,
frankly
speaking,
those
are
not
required.
So
we
want
to
simplify
the
draft
to
get
rid
of
some
of
the
features
which
are
anyway,
common
features
and
expected
to
be
implemented,
and
so
we'll
be
simplifying
the
front
draft
further.
By
removing
some
of
the
features.
D
Also
for
the
statistics,
we
had
created
a
separate
draft
for
the
stats
for
the
qs
model.
The
reason
that
time
was
that
it,
it
required
a
lot
of
discussion
for
every
single
counter
and
we
thought
that
we'll
be
taking
too
much
time
and
we
can
separate
it
out,
but
over
a
period
of
last
several
months
we
have
quite
stabilized
the
counters.
We
are
not
further
changing,
except
that
the
blue
red
counter.
D
We
have
added
this
time,
so
it's
a
pretty
stable
draft
and
we
agree
on
those
counters,
and
so
we
want
to
merge
back
that
particular
stats
module
back
into
the
qs
model
so
that
we
have
a
common
model
for
configuration
as
well
as
for
statistics
yeah.
I
would
like
to
address
and
see
some
of
the
comments
from
the
working
group
on
that.
B
I
see
there's
comments
from
adrian
on
the
chat,
so
probably
we
could
do
it
offline
thanks,
really
good
work
and
we
are
getting
there.
Okay,
thank
you.
Ac
you're.
Next.
B
F
Can
everybody
hear
me
yep,
I'm
ac,
linden
from
cisco,
I
d,
yeah
dogra,
isn't
here
isn't
on
the
call,
but
he's
the
team
lead
for
the
ios
xe
implementation
of
brp
version.
Three
and
steve
natas
was
the
original,
not
the
original
offer
of
vrp,
but
the
original
offer
of
the
of
or
the
offer
of
our
of
our
of
rfc
5798,
which
took
it
to
v3
and
consolidated
stuff.
That
was
in
both
the
existing
rfcs
and
and
a
draft
on
vrp
for
ipv6
next
slide.
F
Now,
unless,
unless
you've
been
living
under
a
rock
you're
aware
that
a
lot
of
the
major
vendors,
my
cisco
and
others
have
adopted
a
plan
to
try
and
replace
their
documentation,
replace
all
the
terminology
that
is
non-inclusive
into
inclusive
and
at
the
same
time
this
was
happening.
You
know
a
few
years
back
and
then
about
a
year
later,
the
ietf
came
up
with
a
with
the
same
and
and
others
I'm
not
really
keeping
up
with
other
standards
organizations,
but
other
standards
organization
did
the
same.
F
So
as
you're
you
know,
from
dating
back
to
80s,
the
whole
terminology
of
master
and
slave
was
very
common
in
networking
protocols.
You
know
in
both
in
the
ietf
and
ieee.
So
what
what
the
main
motivation
was?
We
looked
at
vrp
version,
3
and
rfc
5798,
and
we
could
see
that
just
issuing
the
draft
that
updated
it.
It
was
almost
as
if
every
paragraph
included
the
state
master
I
mean
there.
There
definitely
wasn't
a
page
that
didn't
have
it
and
what
we
chose
was
to
leave.
F
It
wasn't
master
and
slave.
It
was
master
and
backup
in
in
you
know,
in
brp,
since
I
was
involved
with
the
first
one.
It
was
about
in
1994
that
the
vrp
version
2
became
a
standard
ever
since
then
it's
always
been
ma
master
and
backup,
so
we're
retaining
backup
but
we're
replacing
master
with
active,
which
seems
to
be
very
a
very
natural
choice.
F
It
seems
like
it's
consistent
with
other
h,
high
availability
protocols
and
things
to
have
an
active
and
a
backup
and
at
the
same
time,
since
we're
doing
a
biz,
we're
fixing
all
the
errata
errata.
Actually
there
wasn't
that
many
I
fixed
them
after
aditya
did
the
initial
changing
of
all
the
terminology
and
and
and
another
thing
now,
this
time
we're
hoping
to
get
some
good
reviews.
I
don't
I
remember
when
57
98
biz
came
through.
F
I
didn't
think
we
got
I
I
reviewed
it
really
well,
but
I
don't
know
that
we
got
as
many
reviews
as
we
should
have
now.
We
might
investigate
it,
taking
it
to
internet
standard.
I
don't
know,
I
think,
I'm
pretty
sure,
since
this
is
just
really
a
terminology
change,
I'm
sure
we
can
I'm
hoping
we
can
just
leverage
interop
testing,
that's
been
in
the
in
the
past,
we'll
start
a
thread
on
that.
It's
not
a
the
last
one.
F
F
There's
other
rfcs
there's
also
the
vr
there's
rfc
6527,
which
has
the
vrrp
version
3
miv.
Now
we
don't
have
a
film
a
firm
plan,
but
aditya
says
he's
interested
in
doing
this,
so
I
think
he'll.
I
I
think
he'll
watch
this
space
once
we
get
this
one
adopted
for
this.
G
Here,
cair
patel,
arcus,
hey
ac,
quick
question.
It's
great
to
see
you
replace
the
terminology
here.
Are
you
planning
to
do
the
same
with
the
yang
model
for
this
protocol.
F
H
The
jumping
ahead
of
ac-
I
just
let
you
know
I
already
uploaded
their
updated
bfd
and
vrp
document
aligning
with
the
terminology
and
thank.
I
F
Okay,
oh
oh
the
draft!
Yes
that
draft
I
actually
I
did.
I
didn't.
I
didn't
mention
any
drafts
in
this
presentation
only
full
rfcs,
because
I
just
assumed
if
this
gets
accepted.
As
a
working
group
document,
people
will
update
the
dra
the
inner
working
draft
between
bfd
and
brp
and
any
other
drafts
that
pertain
to
vrp.
F
This
one
f
once
once
once
we
get
this
accepted,
and
maybe
it
goes
through
a
reuse
cycle,
this
is
a
very
short
draft.
Rfc,
90,
7910
I'll
contact,
the
offer
jeffrey
and
I'm
sure
it
wouldn't
take
much
to
do
a
biz
on
this
as
well.
F
Yeah,
I'm
a
co-author
of
this
draft,
the
yang
model
8347.
F
So
I
plan
once
again
once
this
one
settles
a
little
bit.
You
know
at
least
gets
accepted
as
a
working
group
document
and
maybe
I'll
start
I'll
start
work
on
this
one.
We
we
know
how
to
do
both
for
the
mibs
and
the
and
even
the
even
the
yang
models,
it's
a
little
painful,
but
we
know
how
to
do
it.
We
can
deprecate.
F
I
think
we
can
deprecate
the
old
tables
and
and
and
bring
in
the
new
tables.
G
Yeah,
careful
archus,
hey
we,
we
would
support
this
work
and,
as
soon
as
you
change
this,
we
we'll
be
more
than
happy
to
show
interoperability
with
the
new
rfc,
as
well
as
the
model.
Okay,.
F
Yes,
that
that
that's
a
that's
a
good
point,
you
know
like
the
mibs,
whereas
the
code
changes
are
pretty
much
just
cosmetic
for
the
base
protocol.
You
know
the
show
commands
or
whatever
the
mib,
the
mibs
and
the
the
mib
and
the
yang
model
will
require
deprecation
of
old
old
tables
in
the
case
of
erp
and
old
yang
nodes
in
the
case
of
of
the
yang
model,
we're
gonna
we,
so
we
we
plan
to
do
that.
I
know
I
know
I
I
did
do
some
work.
F
I'm
gonna,
it's
gonna,
take
more
investigation
to
see
what
the
least
intrusive
way
to
do
this.
The
good
news
is,
I
don't
know
of
any
up
implementations
of
of
this
draft.
I
could
ask
oh,
I
could
ask
the
main
offer
who's
shoe,
fan
I'll.
Ask
him
if
he
knows
of
any.
F
F
I
think
I
think
this
is
a
good
place
for
it.
I
think
vrp,
since
we
don't
have
the
vrp
working
group
and
then
we
could
possibly
discuss
this
terminology,
but
really
we've,
I
think
active,
is
a
natural
choice.
I
know
in
things
like
this,
it
kind
of
gets
in
to
be
a
naming
con
test
and
people
will
put
out
a
suggestion
just
for
the
sake
of
putting
one
out,
but
unless
you
have
a
real
good
reason
to
choose
something
other
than
active,
we
really
don't
need
any
suggestions
and
I'm
requesting
working
group
adoption.
J
F
Yes,
a
matter
of
fact,
we
did
something
with
that
with
with
I
mean
I
I
I'm
not,
I
know
you're
you're
up
on
all
the
tool
kits
and
and
other
things
there's
other
people
at
my
company
who
do
all
that
that
that
kind
of
stuff-
but
I
remember
we
did
the
same
with
when
we
did
the
ndma
model
for
the
the
yang
routing
model.
F
It
was
on
that
it
was
loot.
Me
lou
and
oh
help
me
out.
F
The
guy
from
the
guy
from
prague
who's
in
the
in
the
isp
there.
J
B
C
B
Okay,
so
we'll
talk
to
our
ad
with
regards
to
right
place,
I
think
routing
is
the
right
place
to
treat
all
vrp
bus
drives,
but
we
need
to
confirm
and
ac
thank
you
for
taking
the
work,
it's
important
to
use,
inclusive
language
albert
any
comments
or.
K
Sure,
alberto
donald,
so
as
long
as
we're
here,
why
don't
we
ask
if
there's
interest
in
the
room
here
and
virtually,
of
course
to
take
on
this
work
here?
I
I
believe
it
probably
the
this
is
the
right
place
right
there
there's
no
point
in
spinning
anything
else
up,
so
why
don't
we
ask
that
and
then
we
make
the
decision
of
whether
we
do
it
here
or
we
do
it
somewhere
else.
Okay,.
B
L
B
B
M
M
M
I
will
first
go
through
the
history
of
the
apn
at
ietf.
It
has
been
three
years
since
we
first
started
the
work
and
thanks
to
the
feedback
we
received
from
the
community
and
the
guidance
from
isd,
we
have
been
progressing
after.
We
proposed
the
framework
in
104
and
we
held
our
first
assad
meeting
and
we
gathered
our
initial
interest
team
and
we
started
exploring
valuable
use
cases
and
in
107
we
applied
for
above
for
the
first
time,
but
it
was
rejected
and
we
were
suggested
that
there
were
similar
attempts
in
the
ietf
history.
M
We
had
our
second
above
application.
It
was
tentatively
approved
but
not
held.
Finally,
and
we
were
suggested
to
clarify
the
work
in
wider
community-
that's
why
we
presented
in
the
four
areas
in
one
one,
one,
zero
and
our
third
above
application
was
withdrawn,
and
we
were
suggested
that
a
full
apn
focus.
The
interim
meeting
will
be
arranged
in
rtgwg.
M
Thanks
to
this
arrangement,
we
were
very
well
prepared
for
our
buff
and
our
fourth
wolf
was
approved
and
held
over
200
people
attended
this
world
and
from
all
the
seven
itf
areas
it
showed
clear
interest
and
very
active
discussions.
We
got
a
clear
summary
from
the
chairs
and
the
guidance
from
ad.
That
is
that
we
should
publish
some
solution
drafts
to
show
people
what
are
in
my
in
our
mind
and
from
the
both.
M
We
also
got
some
questions
and
we
categorize
them
in
total
38
issues
and
we
systematically
work
on
them
and
address
those
issues
and
based
on
that,
we
clarify
the
drafts
and
publish
the
new
drafts
and
updates
the
old
ones
and
guyan
cayenne
is
not
here,
so
I
will
continue
so
in
summary,
you
can
see
that
we
have
okay,
so
we
have
presented
the
sixth
time
in
rtdwg
and
we
had
two
set
meetings
and
four
buff
applications
and
three
hacksaws,
and
currently
we
got
over
10
active
drops,
please
you
could
take
the
takeover.
M
N
N
Yes,
so
after
the
apn
buff,
we
had
received
a
lot
of
feedback
from
the
buff
and
we
we've
gone
through
and
compiled
a
list
of
38
open
issues
from
the
buff
and
through
that
we
had
gone
through
systematically
and
addressed
every
every
one
of
the
issues
that
came
up
from
the
apn
as
well
for
immediately
following
the
book
adrian
had
put
together
a
nice
summary
of
you
know:
feedback
from
the
boss,
so
just
compiling
everything,
just
the
entire
of
what
what
it
transpired
through
the
buff
and
and
then
going
through
it
and
systematically
closing
out.
N
N
This
has
all
been
documented
on
the
github
link
and
it's
it's
in
the
top
right
hand
corner
if
anyone's
interested
in
and
looking
at
it.
That
has
all
the
details
of
the
of
the
feedback,
feedback
and
closure
of
all
the
issues.
Next
slide.
N
So
from
the
feedback
and
issues,
there
was
two
key
draft
updates
from
the
discussions
that
we
had,
and
one
of
the
key
issues
that
came
up
through
the
above
was
was
related
to
apn
work
and
apn
and
and
and
related
to
the
limited
trust
domain
and
and
how
that
works
so
and
a
clear.
A
clarification
with
that
is
related
to
apn
is
also
ipn
is
only
applied
to
an
edge
to
edge
tunnel
encapsulation
within
a
limited
domain,
so
from
a
from
a
apn
head
end
to
an
ingress
node
to
an
e-respe.
N
But
it's
encapsulated
so
as
soon
as
the
packet
hits
the
egress
pe,
where
the
de-encapsulation
happens
so
from
a
tunnel
source
to
tunnel
destination.
At
that
time
destination
the
the
apn
header
is
removed
and
then
the
pat
and
then
the
native
packet
is
exited.
So
any
overlay
technology,
mpls
or
srv6,
where
there
is
a
where
there's
an
encapsulation
that
would
be
applicable
to
apn.
You
know
it
would,
within
that
limited
domain
framework.
N
The
other
question
that
came
up
within
the
drafts
and
we
it
within
the
and
when
we've
updated
the
drafts
to
reflect
as
well
as
issues
that
were
closed
out,
was
related
to
an
encryption
domain
and
security
issues.
So
with
that
so
with
the
apn
attribute,
the
attribute
is
acquired
based
on
existing
information
in
the
packet,
such
as
a
five-top
little
q
and
q
provider
and
customer
vln
at
the
edge
of
the
apn
network
and
then
added
added
to
the
data
packet.
N
So
the
clarification
there
was
related
to
an
encryption
domain
and
when
encryption
you
know,
is
present
so
with
apn.
The
attribute
is
acquired
based
on
existing
information
packet
header
and
then
the
clarification
is
the
source
and
destination
address
and
the
incoming
thereto
or
mpl's
encapsulation
incoming
physical
or
virtual
port
information
or
the
fields
of
the
five
tuple
if
they're
not
encrypted.
So
just
other
fields,
not
just
the
five
tuple
as
there
may
be
fields
within
the
fight
within
the
standard,
five
tuple
may
may
not
be
readable,
may
be
encrypted.
O
Hi
yeah
alex,
I
got
either
actually
reaction
to
the
last
slide
where
you
talked
about
the
github
issues,
because
it's
been
it's
been
a
while.
But
if
I
remember
correctly,
I
raised
an
issue
that
I
thought
was
sort
of
pretty
fundamental
and
simple,
namely
what
happens
if
the
application
makes
a
request
that
the
network,
for
whatever
reason
can't
satisfy
and
the
issue
was
closed
and
because,
with
the
resolution
to
be
discussed
and
no
discussion,
as
far
as
I
know
ever
happened
at
this
point,
I
sort
of
felt
a
little
bit
like
you
know.
O
My
attempt
to
engage
wasn't
really
being
taken
seriously,
so
I
I
stopped
and
I'm
hoping
that
wasn't
the
case
for
other
issues
that
were
closed,
but
personally,
I
sort
of
feel
a
little
bit
ambivalent
about
describing
that
all
issues
were
addressed
when
I
feel
mine
at
least
wasn't.
Thank
you.
N
Thank
you
lord.
You
know.
After
you
know,
I've
run
through
this
deck.
If,
if
there's
any
questions,
I
will
have
we'll
have
a
brief
period
that
we
can
go
through
any
questions.
Discussions
related
to
any
of
the
open
issues
that
may
or
may
not
have
been
closed
as
you
had
mentioned.
So
we
would
like
to.
We
want
to
be
open
and
address
any
any
outstanding
or
anything
that
maybe
may
have
been
prematurely
closed.
We
would
like
to
you
know,
be
openly
addressed
any
any
questions.
N
At
this
point,
we
feel
we
feel
that
there
is
a
lot
of
interest
and
support
for
this
work.
We
think
that
in
general,
the
routing
architecture
work-
you
know
that
we
have
with
the
framework
document
is
a
good
starting
point.
You
know
that
describes
the
the
apn
architecture
and
I
think
we
you
know,
we
feel
that
we
are
at
a
good
good
point
with
the
development
of
this
solution
move
forward
with
adoption.
B
This
is
the
third
update
in
routing
and
in
consultation
with
our
ide.
We
strongly
feel
that
routing
is
not
really
a
right
place
for
progress
in
this
document,
so
the
options
are
to
create
another
working
group
with
very
clear
milestones
and
dates
and
how
we
proceed
after
or
proceed
towards
independent
submissions.
K
Sure,
I
guess
I'll
comment
so
just
to
clarify
the
request
is
for
adoption
of
the
framework
and
the
documents
that
are
up
there,
not
for
the
adoption
of
the
solution
documents,
so
it
was
mentioned
before
in
the
slides
there.
So
I
don't
know
10
plus
documents
out
there
somewhere.
K
So
thinking
about
that,
what
that
means
is
that
there
were
probably
if
there
is
interest
right.
You
know.
That's
the
first
of
course
skating
question
right.
If
there's
interest
from
the
community
to
work
on
any
of
this,
there
will
probably
need
to
be
additional
discussion
on
what
any
solution
would
look
like
beyond
the
framework,
which
is
one
of
the
reasons
why
we
believe
that
if
there
is
interest,
I
keep
saying
this
because
that's
the
the
really
important
part
it
wouldn't
be
appropriate
for
the
routing
working
group
to
take
that
on.
K
But
it
would
be
better
to
have
a
focused
discussion
somewhere
else.
So
I
think
we
we
should
start
there
right
and
see.
If
there's
questions
here,
I
see
yari
standing
in
line
somewhere
and
if
there
is
interest
for
us
to
continue
the
discussion
on
adoption
and
if
there
is,
then
we
can
figure
out
what
appropriate
next
steps
would
be
and
where
we
can
constrain
some
of
the
discussions.
P
Yeah,
sorry,
I
didn't
want
to
jump
the
line.
I
was
just
waiting
for
opportunity.
So
did
you
want
to
finish
or
publish
gossip?
P
Yes,
I
just
wanted
to
say
that
in
general,
I'm
actually
quite
interested
in
in
this
application.
Every
networking
area
in
in
in
general
that
I'd
like
to
enable
some
collaboration
between
applications
and
and
networks,
but
unfortunately,
on
this
particular
topic
or
proposal.
We've
had
some
time
passed
by
because,
like
I
guess
from
my
perspective,
we've
been
maybe
a
little
bit
too
ambitious
in
terms
of
what
we're
trying
to
achieve
and
that
has
courts
caused
some
some
issues.
P
If,
if
I
remember
that
the
latest
buff
conclusion,
there
was
actually
two
major
issues,
issue
number
one
was
that
do
we
actually
need
new
end
caps
and
protocols
to
carry
stuff
or
our
existing
ones
sufficient,
so
that
that
was
one
issue.
P
The
other
issue
was
that
several
members
of
the
community
felt
that
that,
if
you
have
two
general
mechanisms
for
carrying
information
in
in
the
package
in
this
manner,
then
there's
a
danger
that
they'd
be
used,
for
you
know
highly
granular
application
or
user
identity
or
or
location
identity
or
some
similar
things,
so
that
might
be
privacy
wise,
not
great.
So
I'm
a
interested
in
like
what
was
the
fate
of
these
two
issues
and
I'm
sure
you
haven't
actually
checked
the
the
github
repo,
but
I
will,
if
you
post,
a
link
there
somewhere.
P
The
other
comment
that
I
had
that
we
separately
have
been
writing
some
of
us
tommy
polly,
amelia
ted's,
a
document
on
in
the
iab
about
path,
signal
collaboration,
draft
iab
path,
signals
collaboration.
I
think
it
is
zero
zero
and
that
document
tries
to
set
out
some
guidelines
on
when,
like
collaboration,
can
can
happen
and
when
it
cannot
for,
for
various
reasons,
whether
it's
privacy
related
or
whether
it
would,
you
know
somehow
limit
the
evolution
of
the
network
in
the
future
or
would
endanger
some
some
issue.
P
So
I'm
not
saying
that
our
zero
zero
draft
has
all
the
right
ideas
it
probably
doesn't,
but
it
will
be
a
useful
exercise
to
take
that
and
run
it
against
the
current
proposal
that
we
have
for
apn
and
see
whether
all
the
suggestions
are
complied
with
or
not,
and
and
that
could
lead
to
either
changes
in
apn
or
changes
in
our
document.
P
I'd
be
happy
to
work
on
that,
together
with
some
some
other
people,
if,
if
you're
interested
it'd
be
nice
to
have
a
test
case
for
for
that
document
as
well,
I
I
don't
have
a
comment
on
this,
like
I
don't
think
this
framework.
Sometimes
I
think
some
of
these
high-level
questions
are
kind
of
very
high
level
that
need
to
be
decided.
The
approach
needs
to
be
decided
before
you
nail
down
the
framework,
but
but
I'm
not
going
to
comment
otherwise
in
that.
Thank
you.
B
Q
I
I
expect
mostly
this
will
come
out
on
the
list
in
the
discussion,
but
the
assumption
that
this
framework
is
the
right
place
to
start
on.
How
do
applications
work
with
the
network
seems
to
be
a
false
assumption
and
the
the
improvements
from
the
addressing
of
the
issues.
Don't
really
change
that
I
do
not.
I
would
love
to
see
us
figure
out
a
good
way
to
get
applications
to
interact
with
and
request
services
from
the
network.
No,
that
is
a
valid
thing.
That's
something
we
need.
Q
It
should
take
into
account
the
privacy
stuff
that
yari
and
company
are
working
on
and
lots
of
other
things,
but
this
framework
is
not
the
right
starting
point
it.
It
assumes
that
the
problem
is
fundamentally
a
routing
problem,
and
I
don't
at
all
think
that
is
the
place.
The
problem
should
even
be
starting.
Q
B
R
Yes,
yep:
can
you
hear
me
yeah
hello,
everyone?
This
time
we
will
update
two
old
draft
problem
statement
and
the
semantic
address.
Also,
we
have
two
new
drafts
today.
I
only
give
a
little
bit
more
discussion
about
third
draft
interactive,
instructive
routing
next
slides.
Please.
R
So
here
I
just
quickly
go
through
our
whole
objective.
Our
objective
is
to
explore
open
solution
for
layer
three
for
large
scale,
eru
constellation
for
internet
access
and
antenna
integration.
Nk
integration
is
a
requirement
from
3gpp
for
next-gen.
R
So
most
people
ask
me
question
which
is
transparent
mode.
It
only
has
a
l1
work,
so
we
are
not
working
for
that
part.
What
we
expect
and
what
we
do
is
we
just
try
to
provide
basic
iep
technology
for
satellite
network
and
we
try
to
seek
the
feedback
from
working
group
and
obviously
this
topic
is
pretty
broad
and
this
presentation
cannot
cover
all
solutions,
maybe
more
draft
we
are
coming
and
we
will
not
do
anything
regarding
to
3gpp
relate
to
3gpp
next
file
space.
R
R
Here
is
the
update
for
the
semantic
address
and
we
only
have
add
one
section:
32-bit
cinematic
address
and
this
picture
shows
what
is
the
address
will
be
look
like.
We
have
three
indexes
and
you
can
either
use
it
with
in
ipv6
or
using
independently
next
slice.
Please.
R
Now
we
come
to
the
new
draft
satellite
interactive
routing,
so
the
purpose
is
to
provide
a
a
rotting
solution
for
satellite
network.
Why
we
need
to
do
this
because
we
have
if
we
use
igp
or
bgp,
we
have
following
challenges:
link
keep
flipping
and
the
link
matrix,
keep
changing.
R
Then
unsteady
link
also
flipping
also
the
possible
link
interruption
at
the
polar
area
above
the
will
cause
huge
igp
protocol
message
flooding
if
we
use
igp.
Of
course,
there's
only
one
protocol
right
now
in
industry
to
to
do
the
advanced
reporting,
so
igp
will
face
a
lot
of
problem
for
this
and
will
automatically
reduce
the
service
time
next
slide.
Please.
R
This
is
a
picture
how
the
satellite
network
looks
like
it
has
two
set
of
satellites
moving
to
two
different
directions
and
we
have
a
terminal
connect
to
satellites
connect
with
user.
Also,
we
have
a
terminal
ground
state,
a
gateway
ground
station
connect
to
internet
also
connect
to
satellites.
R
All
these
links
are
keep
changing
and
the
link
metrics
are
also
keep
changing
and
the
in
addition
to
the
mobility
of
satellites,
the
ground
station
also
keep
moving,
because
the
has
earth's
rotation
so
next
slice,
please.
R
So
if
we
use
igp
for
to
provide
ipconnectivity,
definitely
we
can
do
it,
but
the
problem
is
that
huge
number
of
links
there
and
the
link
is
keep
changing
so
which
will
result
in
the
service
time
dramatically
reduced.
Here
we
have
formula
some
paper
analysis
that
says
only
20
less
than
20
percent
time
will
be
service
time.
All
the
time
will
be
re
in
the
convergence
next
slide.
R
So
when
we
consider
the
solution,
we
have
to
think
about
the
what
is
the
spatial
characteristics
of
the
satellite
level?
R
First
for
satellite
network
according
to
3gpp,
it's
just
the
kind
of
carrier
network
or
the
transport
network,
so
the
only
provided
traffic
transport
traffic
between
satellites
or
between
the
ground
station
and
satellites
and
the
aerial
constellation
has
very
ordered
topology.
Even
it's,
it's
extremely
dynamic.
R
So,
first
of
all,
it's
a
multi-layer
grid
network,
even
interleaved,
and
moving
to
different
direction.
Second,
is
that
its
link
number
is
limited
about
four
to
six
and
also
the
address
as
we
are
proposing
the
semantic
address.
Their
addresses
can
be
self
explained,
so
we
can
use
that
to
identify
satellites.
R
So
the
last
is
a
satellite
position
is
predictable
because
everything
is
following
the
physical
laws
and
the.
If
we
know
the
orbital
elements
we
can
predict,
predict
the
adjacency
and
also
predict
the
link
matrix,
because
the
space
environmentation
is
has
much
less
interference
like
in
our
atmosphere.
R
So
here
we
have
the
principles
for
our
hybrid
solution.
First,
we
want
to
make
maximize
the
usage
of
the
computation
and
in
the
routing,
to
reduce
the
message.
So,
for
example,
we
can
compute
compute
the
network
topology
and
the
link
metrics
also
predict
which
satellite
can
be
can
connect
to
which
ground
station.
R
Second
principle
is
that
we
won't
borrow
the
igp
for
the
satellite
network
topology
and
the
state
detection.
So
one
proposal
is
related
to
the
ospf.
We
can
use
the
ospf
to
to
maintain
the
link
state.
Third,
one
is
that
we
can
utilize
the
semantic
address
for
the
routing
purpose.
R
R
R
We
are
a
couple
of
satellites,
then
we
can
easily
convert
this
to
be
a
couple
of
segments
and
the
segment
is
either
on
the
same
orbit
or
on
the
adjacent
orbit
and
after
com
compressed
to
be
segments.
We
can
convert
to
be
instruction
directly
because
the
we
have
very
limited
number
of
the
forwarding
direction
and
also
very
limited
number
of
the
links.
R
R
So,
finally,
we
have
very
simple
instruction
list.
We
can
embed
it
in
the
packet
next
slide.
R
Sure
next
slide,
so
here
we
give
the
one
user
plan
example,
which
is
a
tunnel
less.
We
just
use
the
introduced
new
routing
type
to
embed
the
instruction
to
be
packaged
next
slides
yeah
here
is
a
summary
of
the
interactive
routing.
I
don't
go
through
each
of
them,
but
compared
with
the
current
solution,
definitely
we
have.
We
can
see
the
advantages
either
in
the
lookup
or
the
memory
or
the
overhead
size
for
the
package,
also
reduction
for
the
isl
link
bandwidth.
S
So
this
is
is
pretty
interesting,
but
I
have
kind
of
a
basic
question
I
don't
think
has
been
addressed,
which
is:
is
this
a
good
candidate
for
standardization?
I
mean
to
to
my
knowledge-
and
this
is
not
my
field.
These
satellite
constellations
are
proprietary
networks
that
are
launched
and
managed
by
a
single
entity.
So
I'm
not
going
to
argue
about
the
the
value
of
the
research.
I'm
just
wondering.
Is
this
a
thing?
That's
a
candidate
for
standardization.
S
R
You
yes
actually
for
that
question.
I
have
some
answer
in
my
problem
statements
workshop.
Why
I
can't
need
to
do
this.
I
have
listed
some
reasons.
Yeah.
B
You're
asking
for
significant
amount
of
work
that
is
large
and
requires
either
new
routing
protocol,
at
least
some
changes
to
mana.
Potentially,
what
are
your
expectations?
There's
significant
number
of
drafts
that
are
progressing
kind
of
asynchronously.
R
Yeah
we
agree.
This
is
a
pretty
broad
topic
and
right
now,
there's
no
dedicated
working
group
in
the
idf.
At
this
moment
we
just
seek
the
comments
from
different
to
see
what
we
can
proceed.
B
There
was
question
from
engine:
the
draft
is
informational.
Is
that
intentionally
or
you
plan
to
change
the
status
eventually
linseries
still
to
you.
B
Yeah
just
give
me
one
minute,
so
if
lynn
comes
up,
he
can
address
it.
I
see
people
positively
reacting
and
asking
to
continue
this
work
in
itf.
It's
still
unclear
where
and
when
so
we'll
continue
the
discussion.
Please
go
ahead
insane.
E
E
And
first
we
use
the
protection
of
sr6
network
by
the
sr6b
and
the
battlefront
first
parts
or
t
parts
by
using
the
policy,
and
if
we
use
the
t
parts,
we
recommend
the
compressed
segment
list
encoding
and
for
the
protection
of
the
sr56
network.
E
Firstly,
is
the
parts
protection,
including
the
local
protection
and
the
e2e
protection
and
the?
Secondly:
is
the
service
protection
also
including
the
local
protection
protection
and
the
third
one?
Is
the
coexistence
of
the
service
protection
and
the
power
protection
and
the
third
part
I
will
introduce
the
running
code
status
in
the
chain
mobile
and
the
fourth
part.
I
will
give
a
very
quick
overview
of
further
examples.
E
For
the
past
protection
and
and
the
first
is
the
local
protection
and
definitely
we
use
the
tfa
and
and
if,
if
the
compressed
sr6
is
enabled
in
the
network,
I
will
recommend
the
gsr6.
E
The
repair
node
should
try
to
use
the
compressed
seed
to
encode
the
tfa
repair
parts
and
to
the
e2e
protection
and
the
candidate
parts
with
the
second.
The
highest
preference
can
be
selected
as
the
backup
parts
and
if
all
the
candidate
parts
fail
and
we
should
use
the
be
parts
and
for
the
limits
check
and
for
the
local
protection,
we
can
use
the
bfd
for
the
interface
or
for
between
the
neighbors
for
the
policy
or
for
the
t
parts,
and
we
can
use
the
bfd
for
the
policy
next
side.
Please.
E
E
We
can
use
the
sr6
seagrass
protection
draft
and
with
the
mirror
seat
and
for
the
e2e,
we
can
use
the
ingress,
node
switchover
and
steals
the
full
flow
to
the
parts
of
the
backup
egress
pe
and
the
liftness
check
recommended
use
the
vfd
for
the
locator
or
the
p
address,
or
for
the
specifically
used
service
seat
and
the
co
instance
of
the
service
protection
and
the
path
protection.
We
have
two
strategies
and
the
first
one
is
the
egress
note
first
and
the
second
one
is
the
t.
E
First
next
slide
will
show
more
clearly
next
step
piece
and
for
the
strategy
and
for
the
primary
and
next
hub
we
for
the
post
of
this
strategy.
E
E
Okay,
this
is
the
radical
status
in
chat
mobile.
We
we
have
finished
the
lab
interrupt
test
last
year
by
using
the
gsi
6
for
the
above
protection
solution
by
using
the
the
controller
from
the
channel
unit
tags
and
by
the
device
from
the
huawei,
h3c
and
dte,
and
also
we
have
a
finished
child
of
the
gfsix
protection
with
above
solution
in
three
province
branch
networks.
I
E
Firstly,
it's
the
sra
6be
deployments,
and
for
this
for
this
example,
we
deploy
the
be
parts
to
the
p3
and
p4
and
the
primary
p
and
the
backup
pe,
and
we
also
deploy
the
vfd
for
the
locator
of
the
both
of
the
pes
and
odd
nodes
enable
the
tfa
nexus
type
piece.
E
And
if
the
egress
pe
failed,
the
p1
will
check
the
switch
over
to
the
sra
6b,
be
part
to
the
backup
p
and
the
p4
nexus.
Please.
E
For
the
sms
6te
diplomats
is,
it
is
more
complicated
and
for
the
to
the
primary
exact
pe,
we
deployed
one
policy
with
the
primary
candidate
parts
and
the
backup
penetrator
pass
with
both
both
of
the
parts
are
the
strict
te
parts
and
we
recommend
use
the
bfd
with
the
forward
parts
and
the
rewards
parts.
E
E
For
the
for
the
policy
to
the
egress
p
primary
b
class
pe
when
the
strict
parts
failure,
the
p1
will
check
the
switch
over
to
the
backup
parts
in
the
same
policy
next
slide.
Please.
E
If
both
of
the
other
parts
fails
and
the
the
p1
will
check
the
the
switch
over
of
the
first
priority
backup,
that
is,
that
means
the
sr6b
parts
to
the
p3,
because
we
use
the
egress
node
first
strategy
here.
E
If
we
use
the
t
first
strategy,
it
will
switch
over
to
the
p4
policy
yeah
next
slot.
Please.
E
And
if
the
primary
egress
p,
the
p3
fails
and
we,
the
p1,
will
switch
over
to
the
e6t
lose
parts
to
the
p4.
B
E
E
If
the
failure
happened
to
the
to
the
long,
endpoint
node,
we
can
use
the
trfa
repair
parts
next,
please
it
will
happen
to
the
endpoint
node.
We
can
use
the
switch
over
to
the
be
parts
and
then
the
desk
or
next
last
piece.
T
E
Other
draft
for
the
for
the
parse
consistency
for
the
spfd
in
the
vfd
working
group
that
you
have
the
details.
U
From
juniper,
I
can't
remember
the
slide
where
you
showed
the
primary
path
and
the
backup
path
to
a
different
egress
e.
I
think
it
was
slide
14,
but
I
might
be
mistaken,
so
my
question
is:
maybe
okay
I'll
assume
p
e4
is
the
not
sure
here
which
is
the
primary
in
which
was
the
backup.
U
U
The
bfd
session
wouldn't
tell
you
the
fault
in
that
case
and
in
in
in
that
sense,
why
is
this
protection
not
done
at
the
service
level
at
the
bgp
level?
Thank
you.
B
U
V
Hello
yeah:
we
can
hear
you
okay,
perfect,
so
no
questions
only
comment.
I
think
it
is
a
really
impressive
presentation.
I'm
really
happy
to
hear
an
operator
can
share
their
real
issues
and
considerations
from
the
test
and
and
deployment
right.
It
definitely
can
and
help
us
on
on
how
to
develop
the
network
in
the
future
and
guide
us
to
drive
the
work
into
the
right
direction.
So
really,
thank
you.
Yep
thanks
jeffrey.
W
Yeah
jeffrey
from
juniper,
I
might
have
missed
it,
but
what's
specific
about
srv6
here
or
what's
what
can
not
be
done
with
sr
mpos?
What's
different.
B
I
don't
think
we
are
going
to
get
an
answer.
Could
you
please
send
it
to
the
list?
I
don't
see
any
reactions
here.
B
So
it's
going
to
be
bark
braga,
instead
of
and
just
to
say
a
few
words.
We
have
discussions
with
transport
area
people
on
this
draft.
It
touches
upon
routing,
actually
quite
a
lot
and
as
many
other
presentations
you've
seen,
we
are
looking
to
ways
where
hosts
can
interact
with
the
network.
So
it's
one
of
those
please
go
ahead.
X
Thank
you
jeff.
Can
you
hear
me.
X
So
yeah
I'm
gonna,
present
hpcc
plus
plus
here,
and
this
is
an
enhanced
high
precision,
congestion
control,
suite
work
together
with
rui
and
and
the
team
here
presented
on
these
drafts.
X
Okay,
so
let's
reiterate
what
are
we
trying
to
address
here?
So
we
started
with
a
focus
on
looking
at
cloud
providers,
environments,
and
there
are
a
couple
of
things
that
happen
in
the
recent
years.
X
That
drove
our
interest,
starting
with
the
high
performance
storage
and
the
change
in
the
storage
environment,
recently
drove
a
much
higher
throughput
and
lower
latency
access
to
the
storage,
and
we
see
order
of
magnitude
of
million
iops
and
about
50
to
100
microsecond
response
time,
and
this
is
a
kind
of
go
order
of
magnitude
less
than
what
it
used
to
be
before.
Ssds
and
energy
were
introduced
to
the
networks.
X
X
All
these
shifts
put
a
lot
of
pressure
in
the
network
because
the
compute
become
much
more
capable
and
much
more
demanding
in
terms
of
the
communication
patterns
in
between
these
devices
as
well
as
lower
latency,
because
because
the
computation
is
distributed,
there
is
a
lot
of
dependencies
between
the
various
nodes
and
this
dwarf
latency,
even
further
down
towards
sub
10
microsecond
requirements
and
even
below
that,
in
addition
to
that
resource
or
memory
disaggregation
in
the
network,
so
their
servers
kind
of
architectural
changes
and
how
we
built
the
servers
or
the
compute
elements.
X
Basically,
because
we
disaggregate
all
these
components
used
to
be
in
the
same
same
box
or
chassis.
If
you
will
now
when
we
dislocate
them,
we
present
latency
from
the
network
and
in
order
to
overcome
it,
we
need
to
give
services
that
are
even
lower
latencies
than
what
we
already
discussed.
So
all
of
these
kind
of
drove
us
towards
looking
into
solutions
to
enable
higher
bandwidth,
consistent,
bandwidths
and
lower
latency,
as
well
as
consistent,
latency
grad.
X
H
A
couple
questions
so
first
there
have
been
comments,
the
draft
before
the
meeting,
and
I
just
wonder
if
offers
notice
them.
H
Okay,
another
question
is
that's
something
that
I
think
that
I
didn't
ask
in
my
comments
is.
X
X
X
Chips
actually
form
hyper
speed
networking.
What
does
it
mean?
We
talked
about
the
application
again,
but
now
not
only
that
the
application
has
been
changed,
but
also
the
hosts
or
the
nic.
If
you
will
has
been
changed
and
we
see
more
and
more
demand
and
installations
of
hardware
awful
being
in
the
nick.
X
So
if
you
look
kind
of
on
the
history
in
the
past,
and
especially
considering
tcp
and
the
like,
what
we
have
seen
is
some
offloading,
mostly
related
to
things,
has
to
do
with
hashing
and
so
on
a
little
bit
handling.
You
know
the
messages
and
cut
them
into
pockets
and
so
on,
but
a
fundamental
change
happened
with
harder
offloading
that
has
to
do
with
rdma
or
remote
direct
memory
access.
X
So
what
are
the
challenges
that
related
to
condition
control
in
high-speed
networks
that
we
discussed
convergence
upon
congestion?
So
if
condition
happens
in
the
network,
then
how
fast
would
the
network
be
able
to
solve
this
congestion
and
and
and
basically
reduce
the
load
in
order
to
be
able
to
prevent
the
condition
and
also
how
fast
will
it
be
able
to
pick
up
one's
congestion
result?
X
So,
as
you're
well
aware,
these
cloud
environments
that
we
began
with
and
later
on,
thought
about
other
use
cases,
they
may
run
multiple
applications
and
the
the
requirement
is
to
be
able
to
not
have
dependency
between
them,
and
this
is
why
costs
and
buffering
your
scholars
resources
in
the
network
as
you're
well
aware,
in
addition,
because
current
conditional
algorithms,
whether
using
ucl
or
not,
has
a
lot
to
do
with
many
parameter
tuning,
it
has
to
do
with
the
fact
that
the
visibility
into
the
network
is
limited
and
then
some
kind
of
heuristics
has
to
be
to
be
made
next
slide.
X
X
Here
I
will
kind
of
present,
I
should
say
an
opportunity
that
has
to
do
with
the
evolving
telemetry
capabilities
in
the
network.
X
So
when
we're
looking
into
invent,
telemetry
or
and
when
I
say
invent
elementary-
and
maybe
this
is
at
least
partly
address
some
of
greg's
questions-
we
refer
to
that
as
the
capability
of
embedding
a
telemetry
on
an
in-flight
packet
as
it
drives
student.
The
network.
X
X
There
is
a
work
under
p4.org,
that's
called
int,
and
there
is
a
graph
suggestion
under
the
name
of
ifa
that
was
suggested
for
ippm.
That
is
not
progressing
as
a
as
a
working
group
after
this
stage,
one
minute
next
slide.
Please.
X
So
can
we
use
this
new
tool
as
a
precise
feedback
for
congest
control?
X
X
So
there
are
a
couple
of
formats,
as
I
mentioned,
because
of
time.
I
won't
get
into
too
many
details,
but
we
are
not
asking
to
discuss
the
format
of
the
packets
here,
just
the
requirements
from
the
inventory
specifications
to
be
able
to
support
data
that
is
needed
from
the
network
for
this
purpose
slide.
Please.
X
So
we
address
all
the
challenges
that
we
discussed
fast
convergence,
so
we
have
a
good
visibility
for
the
senders
near
zero
kills.
We
do
not
need
to
rely
on
q,
build
up
anymore
and
way
less
parameters
to
configure,
because
of
again
this
precise
feedback
that
we
get
from
the
network
and
we
can
take
better
decisions
from
congestion
and
routing
perspectives.
X
So
how
do
we
see
what
hpc
plus
plus
is-
and
this
is
related
to
jeff
comment
at
the
very
beginning?
The
way
we
see
it
is,
this
is
basically
a
service.
It
comes
to
serve
the
networking
entities,
whether
it
is
transport
or
wiring
engine,
but
based
on
this
data
that
is
being
built
in
the
endpoints,
we
can
take
better
decisions
and
serve
the
applications
better,
and
this
is
why
you
know
when
we
came
to
discuss
also
with
some
of
the
transport
teams,
because
it
is
transport
agnostic.
X
X
And
we
will
be
more
than
glad
to
get
the
working
group
feedback
on
the
details
and
on
how
to
proceed.
Thank
you.
B
So,
as
I
said,
there's
an
ongoing
discussion
with
transport
area
ads
and
we'll
keep
you
updated.
What's
going
on
here
and
we've
got
david
black.
O
Hi,
laura
sagar
speaking
as
an
individual,
with
no
dots,
so
I
think
this
is
certainly
interesting
for
transport
and
I
think
the
congestion
control
part
of
this
would
certainly
need
to
be
standardized
there
and
there
are
like
ways
in
which
we
do
that.
I'm
sort
of
the
interesting
question
for
me
in
routing
is
whether
switches
and
routers
would
be
willing
to
provide
this
information.
O
So
if
this
has
no
change
and
there's
the
ability
the
possibility
to
get
this
information
from
the
network,
that
would
be
great
because
it
opens
up
all
kinds
of
things
like
hpcc
and
others,
and
I
think
for
routing
the
discussion
would
be.
You
know,
is
this
something
that
has
changed
on
the
routing
side,
where
the
network
would
be
willing
to
offer
this.
B
Thank
you
and
that's
exactly
it.
We
are
finally
getting
to
the
point
in
time
where
nothing
requiring
can
actually
communicate
back
what
it
does
so
and
again
the
question
where
it
should
leave
really
stays
open
and
ongoing,
but
this
work
is
kind
of
really
important.
The
amount
of
rdma
traffic
in
large
data
centers
is
going
up
exponentially.
B
They
absolutely
need
to
keep
routing
simple
so
using
today's
bgp
css
sharespace
routing.
They
need
better
congestion
control
to
be
able
to
change
entropy
to
reduce
transmit
rate,
and
this
is
really
work.
That's
going
this
direction
when
host
can
interact
with
the
network
and
do
something
useful
with
it.
Dean
it'd
be
cool.
A
Dear
mogranovich,
so
here's
I
have
a
concern
that,
with
the
speeds
that
we
are
approaching
and
the
latency
that
is,
you
know
that
we
are
seeing.
We
are
hitting
that
information
by
the
time
it
arrives,
being
computes
and
being
propagated
back
to
the
source
might
be
already
old,
so
we
have
to.
If
this
really
wants
to
work.
B
J
Y
Getting
a
bit
used
to
this
is
a
a
draft
that
comes
out
of
research,
we've
done
on
dlts
and
provider
networks.
We
try
to
better
understand
what
dlts
as
a
technology
is
doing
to
networks,
and
we
thought
sharing
the
insights
here
with
the
routing
working
group
may
be
quite
useful
because
we're
seeking
input
as
well
I'm
trying
to
see
how
okay
now
it
finally
comes.
Sorry
took
a
bit
so
the
war
games
to
understand
how
what's
the
impact
of
dlts.
Y
If
you
run
dlts,
it
doesn't
question
why
we're
using
dlts
we're
taking
any
dlt
application
there
is.
But
what
happens
to
your
network
when
you
have
dlts
running
on
top
and
and
the
footnote
here
is
quite
important.
We
started
our
insights,
they
were
all
experimental.
We
started
them
based
on
proof
of
work
based,
dlts
ethereum
at
the
beginning
and
we're
still
that's
one
of
the
pieces
that
we're
looking
at
other
dlts
as
well.
Y
Y
We
want
to
get
more
insights,
in
particular
from
from
folks
who
understand
routing
quite
well,
so
you
want
to
want
to
engage
with
the
community
and
and
both
want
to
extend
on
the
impacts,
as
well
as
on
the
opportunities
to
maybe
mitigate
some
of
the
impacts.
Y
Y
Some
of
the
challenges
we're
seeing
as
well
as
the
experimental
insights
that
we
currently
have,
as
well
as
some
of
the
opportunities
for
network
innovations
that
we
also
see
moving
along.
That
may
may
help
us
there.
So,
what's
the
typical
communication
in
a
dlt
for
those
of
you
who,
who
are
maybe
not
that
familiar
with
the
dlt
really
does
the
dlc
is
a
form
for
a
distributed
consensus,
consensus
system
and
we
have
a
client
that
commits
a
transaction
request
to
the
dlt,
a
miner
or
a
peer
generally.
Y
We
call
them
peer,
largely
in
the
draft.
More
commonly
known
are
miners,
for
instance,
for
proof
of
work.
Dlts
commit
a
found
block
to
the
dlt
as
a
piece
of
the
system
of
the
ledger
and
any
client
or
another
miner
may
read
the
blockchain
from
the
dlt,
that's
kind
of
like
the
typical
communication
pattern
or
the
interactions
you
see
in
a
dlt.
Y
In
all
of
this,
it's
important
that
these
operations
are
inherently
multi-point
and
the
nature
of
that
multi-point
is
something
we
in
particular
investigate
with
quite
some
interest,
because
that's
one
of
the
biggest
issues
in
the
dlt
we've
seen
the
communication
pencil.
How
do
you
translate
this?
The
the
key
aspect
that's
being
used
in
the
in
the
dlts
is
the
so-called
pool
of
peers.
To
talk
to
so
the
appears
you're
communicating
the
request,
the
dlt
information
to-
and
this
is
a
very,
very
simple
flowchart.
Y
I
see
there's
something
going
wrong
in
the
flowchart
in
one
of
the
return
paths.
Apologies
for
that
you
find
another
picture
in
the
draft,
so
it
works
off
a
list
of
dlt
pieces
which
is
being
distributed
through
the
network,
and
these
dlt
peers
are
usually
described
as
ip
addresses,
ports
and
and
with
the
ports.
The
protocols
you
you
you're,
maintaining
it
does
no
discovery,
so
it
builds
a
list
of
peers
that
it
understands
it
could
communicate
with,
and
then
it
picks
randomly
from
those
peers.
Y
A
number
of
notes
to
communicate
with
transport
security
is
trying
to
establish
a
capability
exchange.
That's
pertaining
to
particular
protocol
aspects,
security
aspects
you
may
need
to
support,
but
also
hyper
capabilities.
Do
you
have
a
gpu,
for
instance,
if
you
do
a
proof
of
work
dlts,
on
the
left
hand,
side
you
see
the
incoming
peers.
You
may
also
be
contacted
by
an
incoming
peer
who
does
the
same
thing
on
their
side.
Y
Y
You
do
a
type
of
tls
type
of
transport
security,
capability
exchange
and
up
to
the
pool
you're
being
evacuated
from
the
pool
after
some
time,
etc,
etc,
etc,
and
that's
kind
of
one
of
the
biggest
things
that's
happening
in
the
dltps.
Now
my
buttons
disappeared.
Okay,
there
you
are,
while
you're
doing,
there's
a
question
whether
the
pool
is
bounded.
Y
It's
configuration,
it's
all
configuration
50.
It
is
in
the
beginning
by
default
configuration
you
can
set
this
larger,
but
we
run
it
in
the
default
configuration
for
ethereum
thanks.
So
the
problem
is
the
the
one
thing
is
you,
you
require
information
to
reach
other
peers
in
dlts
like
ethereum,
you
have
bootstrap
notes,
so
you
sign
up
to
the
dlt.
You
give
up
your
ip
address,
the
bootstrap
note
seat
the
actual
node
discovery.
Y
It
maintains
the
ip
addresses
of
all
the
miners,
plus
the
port
information,
so
you're
also
indicating
whether
you
have
support
for
udp
tcp,
the
new
dlt
members,
as
you
saw
in
the
previous
slide,
they
need
to
discover
and
maintain
these
addresses
all
the
time
upon
joining
and
they
are
being
refreshed.
As
I
mentioned,
several
thousands
also
clients,
don't
know
anything
about
the
capabilities.
So
I
go
through
this
whole
thing
about
a
contact,
a
potential
miner
I
have
an
ip
address.
I
go
to
the
ip
address.
I
wait
for
the
connection
and
you
notice.
Y
The
waiting
for
the
connect
is
very
bad
if
the
ip
address
isn't
actually
reachable
because
you
have
a
timeout,
so
you're
just
waiting
30
seconds
for
nothing.
You
inquire
the
capabilities
and
any
disconnect
if
they
are
not
matching
and
again,
if
you
run
this
actually
in
an
experimental
setup,
you'll
notice,
there
are
a
lot
of
disconnects
just
simply
because
folks
are
not
meant
to
talk
to
each
other
right.
A
lot
of
these
thousands
of
connections
are
actually
unsuccessful
connections.
Y
The
the
last
problem
that
we
outlined
is
that
you
need
to
expose
the
ip
address.
That's
never
a
very,
very
good
idea,
in
particular,
if
you,
if
you
look
at
the
idea
behind
the
dlt,
and
that
is
communication
between
possibly
inherently
untrusted
parties.
Well,
hang
on
a
second.
Why
am
I
giving
my
ip
address
to
these
people
right?
I
mean
I'm
not
trusting
them
even
on
the
ledger
information,
but
I'm
trusting
them
with
my
ip
information.
Y
So
you
set
an
ip
address:
it
leads
to
privacy
issues,
security
issues,
it's
difficult
to
handle
ip
atlas
changes
because
they
have
to
propagate
from
the
bootstraps
into
the
miners.
If
you
change
your
ip
address,
you
may
still
have-
and
this
is
also
happening
quite
a
bit
in
the
discovery
process-
the
you're
actually
contacting
ip
addresses
they're
all
they're
already
outdated,
and
you
notice
this
by
waiting
30
seconds
right,
nothing's
happening
supporting
mobility
is
another
issue.
Obviously,.
Y
So,
there's
always
a
slight
lag
in
this
one.
The
experimental
insights
there
at
the
moment
taken
from
the
irc
white
paper
we're
also
already
working
on
newer
ones
that
we
will
put
in
another
update
there
they're
constantly
coming
in
with
running
the
experiments
as
they
the
days
go
by
the
different
types
of
their
dlts.
As
you
can
imagine
from
the
from
the
pool
before
from
the
chart,
there's
so
a
fairly
large
number
that
such
is
simply
not
reachable
there.
The
ip
address
is
in
the
bootstrap
node.
Good
luck!
You
try
to
reach
them.
Y
The
ping
never
comes
back.
They
may
just
signal.
We
call
them
just
signaling,
because
you're
going
through
the
capability
exchange
and
nothing
is
really
happening.
You
have
mismatching
capabilities,
but
you
also
may
end
up
in
the
end
talking
to
an
actual
node
after
capability
exchange,
but
they're
sending
you
useless
data
uses
data.
Y
The
data
you
start
with
at
the
very
beginning
is
the
blockchain.
You
want
to
synchronize
on
the
latest
blockchain,
but
you
may
never
end
up
with
actually
getting
any
useful
data
from
them.
Last
but
not
least,
you
actually
have
miners.
You
finally
talk
to
usefully
so
that's
the
last
type
we
identified
and
only
16
of
the
nodes
are
actually
useful.
Y
Y
So
what
are
network
innovations,
we're
outlining
this
in
section
seven
and
section
eight
and
we're
just
starting
there
and
we're
also
reaching
out
in
some
of
the
research
space
and
eight
finn
is
going
to
talk
about
one
of
these
things,
two
presentations
after
this
one,
so
references
to
ongoing
traffic.
We
have
there
there's
some
opportunities
that
we're
looking
into
in
multicast
there's
a
whole
discussion
around.
Why
is
it?
You
can't
really
quite
use
multicast?
If
you
look
at
the
random
nature
of
these
pools,
you
might
guess
why?
That's
the
reason
it's
extremely
dynamic
multicast.
Y
We
also
link
in
the
standardization
efforts
in
the
ieee
dlt
work.
That's
ideal
to
interrupt
work.
That's
been
done
in
a
couple
of
site
meetings,
the
semantic
routing
that
adrian's
going
to
talk
about
later
dynrg
and
we
want
more
input
there.
So
what
are
we
we're?
Having
a
going
to
the
last,
not
quite
the
last
on
the.
Y
Y
I
know
apart
from
ethereum,
we
know
that,
but
we
would
like
to
get
insight
from
people
who
do
work
with
them.
Other
proof
of
work
systems,
proof
of
stake,
which
works
significantly
different
in
the
impact
on
the
overlay
management
insights
into
ethereum
as
well.
We're
doing
this
already,
as
I
said,
as
we
speak,
other
network
innovations,
the
use
of
ip
multicast
list,
that's
something
dino
works
on
that
we're
going
to
talk
also
about
tomorrow
and
the
impact
of
those
network
innovations,
if
you
assume,
doesn't
we're
going
to
take
innovations,
what
would
be
the
impact?
Y
How
would
you
mitigate
the
impact
we
observed
over
traditional
ip
and
that's
something
we
also
work
on?
Most
importantly,
we're
looking
for
collaborators,
so
this
is
meant
to
be
a
living
draft,
so
hopefully
we
get
other
people
to
join
you're
eating
into
your
next
presentation
already
significantly.
Yeah,
yes,
so
we
need
the.
Why
someone?
The
reason
doing
this,
as,
as
I
mentioned,
stay
over
there,
is
to
better
understand
the
impact
of
dlt.
So
folks,
who
have
had
insights
into
dlts
place,
contact
us
we're
very
interested
to
incorporate
that
in
any
updates
any
possible
mitigation.
Y
If
you
worked
on
epic
innovations,
where
you
mitigated
some
impacts,
we
observed
very
good
any
contributors,
please
drop
us
an
email,
there's
also
there's
a
bit
of
advertisement
there
for
a
site
meeting
tomorrow,
that's
going
to
happen
on
dlt
and
networking,
it
will
have
the
spins
of
impact
of
dlts
and
networks
and
the
other
way
around
we're
going
to
talk.
Our
dino
is
going
to
talk
about
lisp
and
what
they've
done
we're
going
to
talk
about
a
bit
more
detail
of
what
I
described
today
already
some
of
the
new
insights.
Y
L
Hi,
this
is
nicola.
One
question:
have
you
looked
at
the
security
implication,
I'm
thinking,
for
example,
about
routing
security?
I
think
there
was
some
research
on
you
know
using,
for
example,
hijackings
for
stealing
bitcoin
or
I'm
also
thinking
about
dos,
for
example,
for
a
leader
based,
you
know,
bfts
is
it?
Is
it
something
that
you
have
been
looking
at
or
just
not
yet
or
so.
Y
So
our
current
focus
has
been
largely
in
quantitative
performance,
but
the
security
part
in
recent
discussions.
So
it's
not
in
the
draft
at
the
moment,
but
certainly
something
if
you
could
send
me,
for
instance
the
research
that
would
be
great
and
as
I
mentioned,
if
I'm
not
trusting
the
dlt,
but
I'm
throwing
my
ip
address
out.
So
it's
it's
quite
clear
that
there
are
a
lot
of
interesting
privacy
and
security
implications.
You
know
on
that,
and
I'd
really
like
to
hear
more
about
that.
Z
Y
Y
That
one
didn't
show
up
before
getting
used
to
the
remote
tool
is
a
bit
buggy
in
places.
So
this
is
a
draft
goes
away
from
from
dlts,
but
even
though
we
are
also
seeking,
obviously
input
by
the
wider
community,
this
draft
talks
about
is
purely
observational.
We
look
at
how
the
internet
has
evolved
from
what
we
usually
in
particular,
very
often
simplistically
teach
people
on
what
the
intent
is
really
doing,
and
that's
reachability
and
it's
it's
title.
Continuing
the
internet
to
evolve
the
internet
riding
beyond
mere
reachability.
Y
It's
intended
to
seat
discussions
and
how
we
can
continue
with
the
observed
evolution
of
the
internal
routing
system,
and
I
said
that
the
draft
is
positioned
as
being
purely
observational,
we're
not
proposing
any
solutions.
We're
just
saying
that's!
What's
going
on!
How
do
we
want
to
continue
doing
this?
Y
We
want
to
engage
with
the
community
on
to
identify
on
possible
next
steps
so
that
this
routing
evolution
that
we've
been
observing
for
the
many
many
years
actually
continues
structure
of
the
draft
there
as
well.
So
we
I'm
going
through
two
three
and
four
section
in
in
in
these
slides,
but
there's
also
obviously
more
discussion
on
the
on
the
issues
which,
which
I
ask
you
to
look
through
the
slides
in
more
detail.
Y
So
we
start
with
the
original
purpose,
so
this
is
kind
of
what
we
usually
tell
people
of
how
the
internet
works
all
right.
So
originally
it's
designed
to
enable
forwarding
iep
packets
to
a
destination
address,
that's
good.
We
have
a
locator
semantic
for
ip
addresses.
That's
fundamental
for
doing
this
usually
assigned
the
context
for
network
topology
so
that
we
can
get
some
sort
of
management
of
this
address
space.
Y
We
have
distributed
decision
making
and
intermediary
routers,
which
sometimes
also
leads
to
issues
and
and
writing
problems
in
particular,
which
some
of
the
extensions
are
are
particularly
interesting
key
when
looking
at
this
is
what's
the
method
for
forwarding
for
selecting
the
path
and
what's
the
criteria
for
doing
so
right,
traffic
engineering
may
help
you
to
avoid
some
of
the
routing
problems.
So
this
is
how
the
routing
system
really
started,
but
okay.
Y
But
there
are
many
many
extensions
to
this
reachability
part,
and
I
said
the
draft
has
gone
through
an
exercise
of
listing
those
and
and
going
through
in
the
end
58
references
that
we
found
so
far.
We
by
no
means
claim
to
be
exhaustive,
but
we
just
wanted
to
start
somewhere.
0.,
so
you
observe
and
survey
those
extensions
and
we
list
them
based
on.
What's
the
purpose
for
the
extension.
What's
the
approach?
Y
What's
the
underlying
technical
approach
and
you
can
just
you
know
we
can
debate
some
of
those
taglines
that
we
used
and
what
are
the
examples?
What
are
the
known
solutions?
So
we
want
to
have
the
evidence
part
right
and
ultimately
we
hope
that
this
may
lead
to
some
sort
of
taxonomy
that
looks
at
the
capabilities
of
a
routing
system
and
the
approaches
for
achieving
those
routing
systems.
Y
So
the
key
observation,
though,
that
we're
doing
with
that
is,
is
that
the
internet
internet
writing
has
been
evolving.
So,
whatever
we
are
saying
about
internet
routing,
maybe
you
know
all
it
does.
Is
reachability
not
really
quite
there's
been
a
lot
of
stuff
going
on.
Obviously
that
has
been
tweaking
and
changing
things
here
and
there
in
order
to
do
certain
purposes
as
we
defined
it
using
certain
approaches.
That's
the
the
observational
part
that
we
have
in
this
draft.
Y
But
if
you
do
those,
we
also
discuss
in
section
four.
What
are
the
possible
issues
when
you
take
these
approaches
and
start
playing
around
with
the
routing
system
in
order
to
achieve
the
purpose
that
you
have
in
mind
right?
That
goes
beyond
pure
reachability
yeah,
and
we
outlined
a
number
of
them
that
are
discussed
in
more
detail
in
the
draft
limiting
routing
capability
semantics,
so
you
fit
the
new
purposes
into
the
limitations
of
the
old
realizations.
Y
There
are
a
couple
of
examples
that
are
given
there,
for
instance,
on
content,
naming
great
idea
to
extend
the
purpose
of
the
routing,
but
unfortunately,
if
you
stick
it
into
the
limitations
of
an
ip
address,
you're
limiting
the
actual
new
purpose
itself
right,
that's
one
of
the
examples.
We
give
complexity
and
efficiency
because
one
minute
yes
or
you
have
repetitive
encapsulation,
you
have
security
fragility
and
operability
number
of
issues
that
are
being
listed.
Y
Y
So
we're
establishing
five
three
sorry,
five,
three
actions
in
the
in
the
traffic
that
we're
suggesting
either
to
establish
suitable
offers
with
efforts
within
routing
working
group
or
to
support
the
establishment
of
suitable
efforts
as
a
standalone
working
group,
which
could
be,
for
instance,
called
the
future
of
internet
routing.
That's
just
the
suggestion
or
support
the
establishment
of
suitable
efforts
within
the
irtf,
where
these
efforts
directly
lays
back
with
the
routing
working
group
through
regular
updates
in
its
meeting.
So
what's
going
on
at
the
moment
there
right.
Y
So
these
are
the
suggestions
we
are
making
in
the
draft
and
what
we
ask
for
is
commons
both
on
the
recognition
and
the
the
suggested
actions
either
here
on
the
list.
We
also
have
this
the
the
manifesto
that
I
linked
in
here,
which
luigi
published
last
year
with
other
courses
and
important.
What
we
want
to
say
is
we
are
not
asking
to
risk.
This
is
something
that
in
exchange
was
was
put
to
us,
we're
not
asking
to
risk
the
investment
of
the
internet
just
to
make
architecture
a
process.
Y
On
the
contrary,
we
want
to
ensure
that
we
have
a
continued
evolution
without
the
issues
that
we
observe
in
the
actual
draft.
So
when
I
ask
you
to
throw
this
all
away
and
open
the
discussion
for
the
pure
research
purpose,
but
actually
really
ensure
that
we
can
continue
doing
routing
evolution
sustainably,
and
I
would
really
need
your
stuff
now.
Thank
you.
Thank
you.
B
While
agent
is
loading
andrea
draft,
a
couple
of
comments,
so
there
is
no
concept
of
subgroup
within
group
in
atf,
rtf,
probably
two
knowledge
had
a
research
group
focused
on
evolution
of
internet
so
bringing
it
to
rtf.
If
you
are
doing
research,
probably
the
right
thing
to
do.
Obviously,
you
can
also
ask
for
working
group
in
itf,
but
this
far
I
don't
think
there's
enough
meat
on
the
bonds
to
really
do
this.
So
if
there
are
significant
interest,
we
can
definitely
have
an
interim
meeting
focused
on
what
you're
trying
to
do
so.
B
B
Robin
could
you
please
send
your
question
to
the
list.
Sorry,
we
are
really
running
out
of
time.
P
I
Okay,
I
will
squeeze
this
into
the
last
11
minutes
no
problem
and
spend
most
of
the
time
reading
the
the
long
title
on
this
slide.
I
I
The
main
things
we're
looking
at
are
things
that
are
not
always
looked
at
properly
when
new
routing
proposals
are
made,
things
like
stability
and
scalability
security,
privacy
manageability
in
particular,
and
interactions
with
other
parts
of
the
network,
so
that
work
breaks
down
into
examining
the
fragilities
in
the
current
system,
in
particular.
What
what
breakages
do
we
often
see
and
the
architectural
considerations
whether
this
is
evolution
or
revolution.
I
And
then
questions
that
we
think
that
research
and
development
should
be
spending
more
time
on
working
out
what
the
deployment
architecture
is,
what
assumptions
of
traffic
patterns
are
are
influencing
the
way
the
design
is
done.
What
is
the
techno-economic
motivation?
In
other
words,
why
are
you
actually
doing
this
work?
Is
it
just
because
it's
fun,
or
is
there
some
driving
force
and
then
beyond
that?
I
I
So
none
of
this
is
attempting
to
criticize
we're
just
trying
to
be
a
little
bit
more
helpful
so
where
this
all
started
was
us
looking
at
semantic
routing
and
we've
we've
heard
a
couple
of
presentations
today,
talk
about
semantic
routing
and
semantic
addressing,
and
this
from
our
perspective,
is
layer,
3
hot,
by
hop
rooting
and
forwarding.
I
So
not
overlays,
not
traffic
engineering.
I
I
So
originally
that
was
all
just
reachability
destination
address
and,
as
dirk
has
just
said,
we're
moving
beyond
that
semantic.
Routing,
then,
is
looking
at
additional
information
that
is
placed
in
the
packet,
somehow,
whether
that's
in
additional
fields
or
overloading
existing
fields
or
partitioning
the
address
space,
and
it's
describing
the
treatment
that
the
package
should
receive
within
the
network.
I
I
This
figure
just
shows
that
architecturally,
it
looks
like
it's
no
big
deal,
we're
sort
of
adding
the
red
words
semantic
into
an
architecture,
but
I
think
this
is
an
overly
simplistic
representation
and
what
needs
to
happen
is
a
better
look
at
the
architectural
implications
and
the
consequences
for
the
routing
system
and
maybe
a
step
back
and
say
what
are
we
trying
to
build
and
and
why
and
how
does
this
all
fit
together?
I
So
as
background
as
we
worked
on
semantic
routing,
we
did
a
survey
and
we
found
that
there
were
an
extraordinarily
large
number
of
pieces
of
work
that
were
in
this
space
and
many
of
them
had
petered
out.
Some
of
them
had
failed.
Some
of
them
had
limited
niche
applicability
and
we
started
to
think
about
the
common
themes
in
researching
and
testing
and
developing
these
ideas
and
the
overlaps
between
other
systems,
in
particular
sdn
and
their
applicabilities,
in
particular
environments,
and
this
led
us
to
formulate
our
challenges
and
research
questions.
I
So
why
talk
to
you
even
about
this?
Well,
we
think
the
challenges
apply
more
widely
to
all
routine
research,
although
we
started
with
semantic
routing
we're
not
trying
to
tell
this
working
group
what
you
already
know,
and
it's
probable
that
they're
one
or
two
people
here
who
have
some
experience
in
routing.
I
What
we
want
to
do
is
firm
up
this
work
with
opinions
from
the
real
world.
So
what
have
we
identified?
That's
not
really
a
problem.
What
have
we
missed
and
what
have
we
left
out.
I
So,
what
are
we
going
to
do
with
this
work?
As
authors?
We're
not
completely
sure
we
don't
know
where
to
discuss
it.
We
do
have
a
place
for
discussing
semantic
routing,
that's
on
a
disk
mailing
list,
and
maybe
the
chairs
here
would
be
happy
for
us
to
talk
about
it,
a
bit
more
in
rtgwg.
I
Obviously
we're
going
to
polish
and
extend
and
take
feedback
from
you
guys,
and
that
sort
of
takes
me
to
this
slide,
which
is
is,
is
what
we're
doing
useful
or
a
waste
of
time.
Are
there
things
we
have
that
are
wrong?
What
else
should
we
include,
and
where
should
we
discuss
it?
There
you
go
chairs,
you
have
two
and
a
half
minutes.
B
AA
People,
please
be
quick,
okay,
some
discussion
in
korea
about
it.
So
could
you
please
brief
us?
The
process
here.
I
I,
what
I
can
say
is
we
we
talked
to
the
irtf
chair
and
he
said,
try
talking
about
this
in
the
coin
rg
we
did,
and
the
coin
rg
chairs
told
us
that
routing
is
not
really
in
scope
for
coin
rg,
so
we're
happy
to
to
have
a
home,
but
we
don't
have
one
at
the
moment.
AB
In
my
question
is
that
what's
means
the
internet
routine,
so
I
mean
that's
the
your
new
thesis
today
talk
about
the
ceramic
routine,
but
if
we
use
used
for
the
truly
the
internet,
so
I
think
that
maybe
that's
the
research
work
that
take
a
long
time
I
used
to
use
for
the
limited
domain,
such
as
satellite
network.
That's
maybe
engineering
work
am
I,
for
my
suggestion
is
better
to
distinguish
the
different
scenario
for
this.
For
this
internet
routine
usual
semantic
address
routine.
T
Jeff,
I
adrian
two
quick
comments,
comment
one.
I
think
this
is
useful
work
and
I
would
like
to
see
it
carried
forward,
regardless
of
what
group
it
ends
up
in
comment.
Number
two
is
that
you
have
a
very
good
list
and
I'd
like
to
suggest
that
you
add
to
it
incremental
maintenance
of
the
mechanism.
That's
the
thing
that
you
usually
enjoy.
U
Derek
tarksad
with
juniper,
thanks
adrian
for
the
great
presentation,
haven't,
read
the
draft.
I
admit
I'll
promise
to
read
it.
It's
not
a
question.
It's
a
comment.
U
I
see
resemblance
in
semantic
routing,
what
you're
proposing
on
semantic
routing
and
some
work
we
myself
and
our
co-authors
are
driving
in
teas
working
group
where
we
carry
something
in
the
packet
that
influences
the
packet
forwarding
or
the
routing
decision
on
the
on
on
on
hops
along
the
path.
I
I
think
this
work
is
useful
and
just
wanted
to
make
that
comment.
Thanks.
I
Yeah,
thank
you
tarek,
and
I
should
add
that
to
the
survey-
and
you
know,
you'll
notice
that
apn
talked
about
earlier
also
influences
the
the
path,
and
I
think
that
a
question
that
needs
to
be
looked
at
more
generally
is
whether
there
should
be
an
attempt
to
do
a
generic
approach
rather
than
picking
environment,
specific
or
solution,
not
solution,
use,
case,
specific
approaches
and
ways
of
doing
this.
I
Maybe
we
can
come
acro
come
away
with
some
generic
encoding,
that's
a
little
more
capable
of
being
used
in
many
different
scenarios.
I
think
that
might
help
the
implement
implementers.
I
If
we
can
do
it
in
a
way
that
isn't
too
costly.
Z
Hi,
can
you
hear
me
yeah?
Yes,
okay,
thank
you,
so
I
just
wanted
to
to
follow
up
on
the
comments
about
coinage
about
how
this
has
been
handled
in
the
irtf.
I
think
that
the
feedback
I
gave
to
adrian
previously
was
not
to
take
the
work
to
coinage.
Z
It
was
the
parts
of
the
work
overlap
with
the
scope
of
coinage,
and
I
agree
that
coin
rg
is
not
a
routing
group,
but
what
coin
rg
is
looking
at
is
how
the
network
is
becoming
more
programmable
and
some
of
the
implications
of
in-network
computation
and
programmable
data
planes
and
so
on,
and
that
I
think
overlaps
with
some
of
the
the
discussions
you
know
in
teas
group.
Z
Z
Although
that's
clearly
not
everything
here,
I
would
probably
argue
that
parts
of
this
work
also
overlap
with
the
ic
energy
and
perhaps
some
of
the
topics
that
were
mentioned
in
the
previous
talk
or
so
overlap
in
that
space,
because
that
group's
considering
what
happens
when
the
you
know,
the
routing
identifies
content
and
the
forwarding
identifies
contents
rather
than
ip
addresses,
but
but
yes,
I,
I
certainly
agree
that
most
of
this
does
not
seem
in
scope
for
the
I
I
rtf
it
seems
much
closer
to
engineering,
although
the
feedback
I've
given
in
the
past
is
that
parts
of
it
fall
within
the
scope
of
some
of
the
the
irtf
groups.
B
I
I
have
nothing
to
add
to
that,
so
the
work
seems
to
be
really
interesting
and
it's
common
theme
for
half
presentations
here.
So
something
is
going
on
and
personally
I
would
really
like
to
make
something
of
this
work,
whether
we
call
semantic
routing
or
policy-based
routing
on
steroids
right.
The
willingness
to
extend
route
lookups
beyond
destination
ap
address
is
definitely
present,
so
we'll
discuss
with
our
id.