►
From YouTube: IETF114-INTAREA-20220728-1400
Description
INTAREA meeting session at IETF114
2022/07/28 1400
https://datatracker.ietf.org/meeting/114/proceedings/
A
C
A
A
D
A
A
Therefore,
we
have
this
reminder
that
ietf
policies
on
topics
of
patents
and
code
of
conduct
how
to
present
yourself
and
address
your
colleagues
are
in
effect
by
participating.
You
agreed
to
do
you
agree
to
the
ietf
poli
processes
and
policies
and,
of
course,
if
you're
aware
of
any
contribution
covered
by
patents,
please
speak
up
or
send
us
a
note
to
the
to
the
chairs.
A
Also
for
your
information,
everything
here
is
going
to
be
written,
audible,
written
audio
and
video
and
photo
will
may
be
made
public
and
the
personal
information
that
you
provide
to
the
atf
will
be
handled
accordingly
to
the
idf
privacy
statement.
If
you
have
any
questions,
you
have
the
references
there
to
the
different
pcps.
A
We
will
ask
you
to
use
mythico
to
join
the
queue
so
that
we
can
control
local
and
remote
participants
and
the
order
of
questions
keep
audio
and
video
off.
If
you
are
not
using
the
on-site
version,
we
ask
you
guys
locally
to
wear
masks
unless
actively
speaking
out
of
the
mic.
If
that
makes
your
voice
clearer
you,
you
may
be
able
to
remove
your
mask
at
the
mic
and
for
the
remote
participants.
Please
make
sure
that
your
own
video
are
off
unless
you're,
cheering
or
presenting
the
decision.
A
D
E
A
So
with
that
we
can
move
on
to
the
agenda.
We
have
a
compact
but
dense
agenda,
starting
with
a
few
updates
that
we're
going
to
give
followed
by
threads
presentation
on
the
ip
parcels
together
with
some
other
drafts,
then
we
have
the
internet
addressing
considerations,
follow-up
from
luigi
ayana
considerations
from
don
eastlake
and
service
routing
and
multi-access
edge
computing
from
zongping.
A
The
other
update
is
the
internet
addressing
considerations
draft
from
luigi.
It's
been
moved
out
of
inter
area.
This
was
draft
gi
into
area,
internet
addressing
gap,
analysis
and
now
it's
draft
internet
addressing
considerations
so
same
thing.
We
are
going
to
have
luigi
presenting
and
giving
us
an
update
about
his
draft,
but
these
are
pretty
much
the
the
working
group
update
so
far.
A
F
A
G
A
G
So
today's
public
internet
is
a
single
monolithic
grounding
and
addressing
domain
instead
of
network
of
networks.
It's
because
there's
incomplete
architectural
layering,
private
intranets
connect
to
the
internet
via
security
devices
like
firewalls
proxies
and
ads,
but
they
use
address
translation
so
that
there's
no
true
end-to-end
global,
addressing
and
internet
working
between
private
internets
is
problem
problematic
due
to
addressing
the
security
incompatibilities-
and
this
complicates
global
mobile
internet
working.
G
But
the
early
pioneers
envisioned
a
true
end-to-end
communications
over
a
global
scale
network
of
networks,
and
they
even
had
a
name
for
it.
They
called
it.
The
cat
net
name
model
for
internet
working
and,
I
believe,
we're
at
a
unique
point
in
history
where
the
end
to
end
can
be
restored
next
chart.
G
So
here's
the
cabinet
model
for
internet
networking,
the
figure
that
you
see
on
the
right
is
the
one
originally
drawn
by
spin
surf
in
1978.
It
was
documented
in
48,
which
was
the
precursor
to
the
rfc
series.
I
incorporated
still
earlier
concepts
from
leopos
on
beginning
in
1974,
and
it
envisioned
a
true
network
of
networks.
G
They
knew
at
that
time
that
gateways
were
required
to
interconnect
diverse
internetworks,
but
they
did
not
know
how
to
traverse
them,
and
they
knew
that
end
systems
also
required
a
local
gateway
to
support
the
end
to
end
what
they
did
not
know
at
that
time
is
that
they
needed
a
new
architectural
layer
and
that
we
called
the
adaptation
layer.
Arrow
and
omni
now
provide
an
adaptation
layer
for
the
internet
next
chart.
G
So
here
we
have
four
disjoint
internetworks.
They
might
be,
for
example,
large
corporate
enterprise
networks,
service
provider
networks.
One
could
be
the
global
public
internet
itself,
the
global
ipv4
internet.
Another
could
be
the
global
ipv6
internet,
but
they're
in
disjoint
partitions.
So
next
chart.
G
So
if
we
deploy
gateways
that
operate
at
the
adaptation
layer,
we
can
now
span
these
disjoint
partitions
next
chart
and
thereby
have
end-to-end
communications
both
within
the
same
partition
and
across
partition
boundaries
by
using
adaptation
layer
forwarding
over
the
gateways
and
over
partitions
next
chart,
so
that
what
happens
is
an
original
ipv6
packet
ending
starting
down
in
the
bottom
left
becomes
encapsulated
in
the
adaptation
layer,
which
is
that
orange
encapsulation
that
you
see
then
fragmented
if
necessary
and
then
encapsulated
again
as
carrier.
Packets
is
what
you
see
in
this
green
layer.
G
The
green
carries
the
packets
across
the
individual
segments.
The
orange
carries
the
packets
across
the
adaptation
layer
gateways
and
at
the
very
far
upper
right.
You
see
that
the
original
packet
then
comes
out
at
the
other
end
after
decapsulation
and
reassembly
next
chart,
so
the
omni
adaptation
layer,
it
and
or
near
end
systems
configure
an
omni
interface,
which
is
essentially
the
same
thing
as
what
the
catnip
model
called
the
local
gateway,
the
omni
adaptation
layer,
source
uses,
ipv6
encapsulation
fragmentation
to
produce
oil
packets
and
then
uses
l2
encapsulation
to
produce
carrier
packets.
G
G
G
The
ol
source
produces
packets
and
fragments
and
the
old
destination
reassembles
and
the
aol
gate
gateways
forward
the
ayl
packets
at
a
layer
below
ip,
but
all
above
the
link
layer.
You
can
see
where
that
bend
in
the
green
graph.
There
happens
at
the
adaptation
layer
and
below
ip,
but
above
layer
two
and
the
carry
packets,
transport
oil
for
packets
or
fragments
across
first
top
segments,
then
undergo
re-encapsulation
and
re-transmission
at
each
next
top
segment,
and
this
provides
us
the
opportunity
for
true
end-to-end
in
the
spirit
of
the
cabinet
next
chart.
G
So
now,
let's
talk
about
aero
omni
and
the
six
m's
of
modern
mobile
internet
working.
The
adaptation
layer
naturally
eliminates
many
challenges
that
complicate
diverse
mobile
internet
and
service
models,
incremental
deployment
on
existing
networks.
There's
no
need
for
a
flag
day.
Security
is
addressed
at
all
layers
in
the
architecture,
including
end-to-end.
G
It
naturally
supports
dtn
and
the
6ms
that
I'm
talking
about
are
multi-link
multi-net
mobility,
multicast,
multi-hop
and
mtu
assurance,
and
all
six
of
them
deserve
a
30-minute
time
slide
in
their
own.
But
I'm
not
going
to
talk
about
all
six
today.
Just
understand
that
they're
very
important,
but
what
I
am
going
to
talk
about
is
mtu
assurance.
The
ability
for
mobile
nodes
to
send
packets
of
diverse
sizes
without
loss
and
to
dynamically
tune
packet
sizes
for
best
performance,
and
it's
inspired
a
new
construct.
That's
known
as
the
ip
parcel
next
chart.
G
Instead
they
put
as
many
of
the
small
items
as
possible
into
one
or
a
few
larger
boxes
or
parcels,
and
then
they
place
the
parcels
on
a
semi
truck
or
an
airplane.
The
parcels
arrive
at
a
regional
distribution
center
where
they
may
be
further
redistributed
into
different
size
parcels
that
are
finally
delivered
to
the
consumer.
G
Next
chart
ip
parcels
are
formed
by
putting
together
segments
that
come
from
the
same
upper
layer,
protocol,
5,
tuple,
being
the
source
address,
destination,
address,
source
port
destination,
port
and
protocol
to
produce
buffers
with
up
to
64
segments
all
concatenated
together.
All
segments
except
the
final
segment
must
be
equal
length.
G
They
can
be
up
to
65k
octets
64k,
octets
minus
the
length
of
the
headers.
The
final
segment
may
be
smaller
and
the
upper
layer
protocol
delivers
the
data
buffer
and
non-final
segment
size
to
the
ip
layer
and
from
there
the
ip
layer
forms
parcels
by
appending
jumbo
a
jumbo
payload
option.
It's
the
same
jumbo
payload
option
that
appears
in
rsc
2675.
G
G
They
include
up
to
64
upper
layer
protocol
segments,
but
only
one
tcp
or
udp
ip
header
and
the
tcp
udp
checksum
covers
only
the
headers
with
an
individual
trailer
for
each
segment.
All
set
all
checksums
are
calculated
in
a
single
pass
over
the
data
for
tcp.
Only
each
non-first
segment
is
appreciated
for
by
a
four
octet
sequence:
number
header
and
udp
transports
encode
their
own
star
delimiter.
In
each
segment.
Therefore,
they
don't
need
the
sequence
number
header
and
these
sequence,
number
headers
and
checksum
trailers
can
be
thought
of
as
a
compressed,
tcp
or
udp.
G
Next
chart
a
transmission
of
ip
parcels,
ip
parcels,
travel,
traverse,
parcel,
capable
links
with
sufficient
mtu
the
same
as
packets,
partial
capable
physical
links
are
not
yet
available,
but
omni
virtual
links
can
forward
ip
parcels
using
the
adaptation
layer.
Today,
the
omni
adaptation
layer
uses
encapsulation
and
fragmentation
to
break
large
parcels
into
smaller
sub-parcels
if
necessary,
since
the
largest
that
can
undergo
ip
fragmentation
is
64k
in
the
first
pass.
We
have
parcel
fragmentation,
which
is
accompanied
by
loose
reassembly
with
opportunistic
merging
in
the
second
pass.
G
We
have
ip
fragmentation,
which
has
strict
reassembly
with
fragment
retransmission,
but
the
goal
is
to
forward
the
fewest
and
largest
ip
parcels
possible
over
the
network
to
the
final
destination,
to
minimize
segment
reordering
due
to
parts
reparcel
if
possible.
Although
that's
not
critical,
we
leverage
ip
fragmentation
reassemble
if
necessary,
and
the
lost
unit
is
a
single
segment.
Instead
of
the
entire
parcel.
G
G
But
after
a
partial
path,
qualification
parcels
from
source
traverse,
partially
capable
past
the
same
as
ordinary
ip
packets
up
to
the
destination.
Router
destinations
that
receive
parcels
can
effectively
deliver
them
to
upper
layers
and
router.
Routers
that
terminate
partial,
capable
paths
open
the
parcels
and
forward
individual
ip
packets
to
the
destination.
G
G
G
G
D
H
G
With
tcp
options
they
would
appear
only
in
the
tcp
header
of
the
first
parcel.
If
it
gets
broken
out
into
multiple
parcels,
they
would
still
only
appear
in
the
first
parcel.
The
other
parcels
wouldn't
carry
the
option
and
it's
the
same
thing
same
with
the
tcp
act
flag.
The
tcp
act
would
only
apply
appear
in
the
first
parcel,
not
in
all
partial
subparcels
after
partialization.
E
E
E
When
we
presented
the
update
on
both
documents,
the
problem
statement,
he
provides
basically
a
scenario
that
we
have
today
in
the
internet,
where
the
the
addressing
model
that
we
have
it
can
be
a
potential
entrance.
So
maybe
sometimes
things
can
be
done
in
a
different
way.
Then
there
was
the
second
document,
the
gap
analysis
that
investigated
a
little
bit
more
about
these
scenarios
and
actually
also
looking
what
kind
of
extensions
in
in
some
areas
have
been
introduced
in
order
to
to
go
beyond
what
was
looking
like,
like
some
limitations
or
shortcomings.
E
E
E
They
have
usually
to
discuss
various
things:
okay,
but
one
of
the
discussion
items
in
their
agenda-
and
there
is
a
snapshot
here-
was
exactly
about
internet
addressing.
Okay,
if
you
did
you,
if
you
go
on
the
wiki
of
the
iab
ist,
you
can
find
the
agenda
and
then
even
the
link
to
the
slides,
okay,
which
I
took
the
liberty
to
use
a
few
of
them
since
they
were
public.
I
must
have
handled
this
in
a
different
way.
E
I
Okay,
thank
you
reggie.
So
my
name
is
eric
vince,
I'm
the
internet
area
director
and
indeed
those
slides,
were
prepared
by
colleen
perkins.
It's
maybe
in
the
on
the
meeting
right
now.
Basically,
because
we
were
seeing
a
couple
of
drafts
about
this,
we
sometimes
kind
of
hey
colleen
nice
that
you
were
able
to
join
us.
I
We
were
wondering
basically
where
what
was
the
intent
of
uvg
at
this
point
of
time,
so
we
reuse,
basically
the
the
retreat
to
say
those
two
documents
and
that's
what
I
wrote
on
the
right.
There
are
multiple
authors
a
little
bit
too
much
right
too
many,
but
it's
okay,
including
academic,
and
you
are
also
ex-academic
there
and
there
were
basically
multiple
gaps
in
those
addresses.
I
It
was
a
quick
summary
of
your
draft,
basically
on
about
the
length,
sometimes
about
the
semantics,
the
confusion
between
locator
and
anti-fire,
which
I
think
everyone
will
agree
with
you
on
this
one,
except
for
the
name
of
gaps.
That's
the
reason
why
I
put
there
because
it
works
right.
The
internet
works
and
basically
you
were.
The
authors
were
making
this
statement
and
I
don't
disagree
with
and
proposing
nothing
right
to
do
and
it
was
kind
of
puzzling
for
us.
That's
the
context
of
this
slide.
E
Exactly
and
no
I
I
agree
totally
what
you
said:
it's
cool
that
you
see
that
there
are
several
outers.
Yes,
the
use
of
caps,
maybe
is
not
the
right
working
wording
will
come.
This
is
the
reason
actually
why
there
is
a
a
change
of
naming
in
the
document
and
we'll
talk
about
this.
I
think
in
the
next
slide
no
solution
proposed
this
was
absolutely
important.
As
we
say
in
the
problem
statement.
E
The
document
is
really
not
about
proposing
specific
solution,
but,
as
I
put
it
in
the
awkward
bubble,
is
I'm
that
stimulating
discussion?
Okay,
so
there
was
no
intention
to
to
to
go
into
the
solution
space,
or
at
least
not
yet
okay.
Next,
so
coming
back
to
the
fact
that
the
the
gap
analysis,
it's
true
that
the
feedback,
basically
as
eric
says
that
you
use
the
word
gap,
looks
like
there
is
a
real
issue
and
you
use
a
gap
to
to
describe
something
missing
between
two
things.
One
is
the
current
state.
E
The
other
is
the
proposed
solution,
but
we
don't
have
the
second
one,
so
there
is
no
gap
in
that
sense
and
we,
while
we
did
some
effort
not
to
to
present
like
there
is
an
issue
in
the
ip
addressing
or
maybe
we
still
use
too
much
the
word
in
the
issue
in
the
previous
version
of
the
document.
So
after
discussion
with
eric
and
the
chairs,
we
agreed
that
on
the
mailing
list
that
the
the
word
consistent.
E
E
The
type
of
content
already
shows
that
the
word
issue
issues
disappeared.
Okay,
the
point
is
not
to
to,
and
it
has
never
been
to
say,
ipad
dressing
is
bad,
it's
good
it.
It
works
perfectly.
There
are.
There
are
some
scenarios
where
some
solutions
have
been
developed
to
overcome
some
limitation.
Now
the
question
is:
can
we
do
it
in
one
coherent
way?
Okay,
instead
of
have
point
solution
here
and
there
that
sometimes
may
be
incompatible
and
sometimes
can
end
up
being
introduced,
some
kind
of
of
fragility.
I
So
that's
another
slide
from
the
retreat.
As
luigi
kindly
indicated
at
the
below,
we
were
really
wondering
what
to
do
with
those
drafts
or
what
the
best
suggestions
to
move
forward
with
your
work
or
there
was
about
creating
a
research
group
making
an
ieb
workshop.
Just
on
this
topic,
possibly
creating
a
new
working
group
or
keeping
an
interior.
I
E
E
J
E
E
Okay,
it
is
just
one
detail
is
that
they
that
are
mentioned
and
arena.
I,
I
suppose
you
guys
discussed
also
this
but
yeah
other
than
that
I
mean
this
is
the
the
the
let's
say
what
should
be
done
in
order
to
go
for
a
new
working
group
I
mean
there
are.
We
know
the
procedure
that
there
is.
We
know
there
is
much
work
to
be
done
and
the
community
has
to
be
there.
I
Something
which
is
you
were
right,
so
sagan
and
raina.
Different
topics
are
not
really
related
to
this,
but
we
put
in
a
retreat
in
the
same
bucket
so
forget
because
it
was
not
linked
to
your
draft
and
the
incremental
move
is
really
what
will
be
important
for
the
next
step
right.
We
don't
want
to
invent
a
pv10
right.
Yes,.
E
I
think
all
the
main
areas
doesn't
mean
necessarily
that
we
we
we
have
to
find
a
solution
from
each
and
every
area
I
mean
this
is
something
also
to
be
discussed
and
decided
as
a
community
and
and
to
decide
whether
or
not
something
should
exactly
be
done
in
the
different
areas.
So
I
mean,
as
has
been
marketed,
let's
not
boil
the
ocean,
let's
focus
on
something
that
makes
sense.
Okay,
next.
E
Eric
you
want
to
say
something:
this
is
just
the
other
slide
on.
The
in
the
area
is
a
is
an
except
of
the
the
chartered
but
which
rightfully
says
what
should
be
done
here
is
something
that
doesn't
fit
in
any
working
group
in
the
internet
area,
but
is
not,
let's
say
enough
to,
or
was
it
to
create
a
new
working
group.
E
J
E
Thank
you,
sir.
I
totally
agree
with
you
in
the
sense
that
what
whatever
will
end
up
doing
this
must
be
incrementally
deployable
and
also
there
is
a
work
to
be
done
on
the
scope
on
what
we
want
to
do.
It's
not
just
oh,
let's,
let's
revise
the
the
addressing
model.
It's
not.
That
is
where
why,
where
what
are
the
areas
where,
if
we
do
something,
we
get
real
benefits
and
how
do
we
do
it
in
order
to
be
incrementally
deployable?
That's
the
the
question.
C
K
I
Oh
yeah,
I
know
you
were
painting
to
me.
Andrew
ib.
Workshops
are
managed
by
iab
right,
clearly
an
outcome,
the
site
meeting
I
mean
everything
is
in
flux
because,
honestly,
the
problem
is
not
well
scoped
right,
there's
a
reason
why
the
assad
meetings
may
be
both
later
or
maybe
ib
workshop,
so
yeah
everything
is
possibly
open.
E
L
Luigi,
I
appreciate
the
goals
and
you've
gotten
in
writing
into
this
document.
You
and
I
have
talked
about
it.
Yes,
but
I
can't
figure
out
how
to
use
this
document
as
it
currently
lives
as
a
basis
for
any
discussion
for
what
to
do
next.
The
document
mixes
things
that
are
done
with
things
that
have
been
proposed.
L
I
don't
know
how
one
would
even
put
together
either
a
charter
or
further
discussions
in
this
group
without
significantly
more
clarity
in
what
it
is
we
are
actually
talking
about.
I
mean,
if
you
want
to
publish
it
as
a
survey
paper
in
sitcom,
hey,
you
do
good
work,
but
that's
not
what
we
do
here
at
the
ietf.
E
So,
thank
you
very
much
joel.
You
have
good
points.
Let
me
answer
that
two
things
one
is
especially
then
the
consideration
document,
as
we
discussed
by
email,
could
be
better
reorganized.
I
and
some
some
thoughts
that
are
there
are
not
clearly
spelled,
so
there
is
quite
some
work
to
be
done,
but
it's
I.
E
As
I
said
in
a
in
a
few
slides
before
the
the
point
was
to
trigger
discussion,
which
is
the
reason
I'm
here
right
now,
if
we
do
agree
that
there's
something
to
be
seen
now,
we
need
to
work
in
in
in
another
direction
and
go
exactly
where
you
said:
try
to
transform
these
documents
in
something
that
can
be
used
to
structure
a
charter,
a
discussion
or
something
like
that.
So
there
is
work
to
be
done
in
that
direction.
I
completely
agree.
B
There
are
some
aspects
which
are
very
straightforward:
engineering,
extensions
to
existing
protocols
and
there's
the
they
cover
the
whole
range
in
between
them
and
given
the
the
breadth
of
the
drafts,
it
is
very
difficult
to
know
where
the
work
should
go,
because
the
work
doesn't
seem
to
have
a
focus.
It
doesn't
seem
to
be
so
much
research,
but
you
know
or
clearly
research,
because
it's
covering
about
three
or
four
different
research
groups.
It
doesn't
seem
so
much
to
be
engineering,
it's
not
sure
where
it's
going.
B
So
I
I
would
echo
the
previous
comments.
If,
if,
if
you
can
focus
the
work-
and
you
know
decide
whether
you
wish
to
do
research,
if
you
wish
to
do
engineering
and
focus
it
down
on
a
specific
topic,
I
think
you
will
find
it
easier
to
make
progress,
or
at
least
it's
a
definitive
answer.
Where
progress
should
or
shouldn't
happen.
E
Sure,
thank
you.
Thank
you,
colleen.
That's.
A
good
comment
is
on
the
lines
like
joel
said.
I
I
do
agree.
That
is
broad
again.
The
reason
is
very
simple:
we
we
try
to
to,
let's
call
it
a
bibliography.
As
charles
said
we,
we
went
broad
to
see
what
what
is
going
on
doesn't
mean
we
need
to
tackle
each
and
every
different
area
or
different
scenario,
etc,
etc.
E
So,
certainly
there
is
a
big
work
to
be
done
in
order
to
scope
the
the
things
and
in
which
direction
we
want
to
go
and
might
this
change
the
venue,
maybe
maybe
the
the
point
at
the
beginning,
really
was
to
trigger
discussion
not
to
to
drive
discussions.
That
is
why
we
went
broad
so
that-
and
everyone
can
have
a
say
on
this,
and
we
will
continue
to
do
in
this
way
so
and
try
to
to
set
the
priorities
according
to
what
the
community
feels
are
the
priorities
or
the
most
promising
direction
to
to
explore.
E
H
Thank
you
stu
card,
and
this
time
I'll
say
my
affiliation
is
with
ax
enterprise.
So,
on
the
one
hand,
I
think
this
work
is
fundamentally
important
and
I
believe
that
having
a
venue
in
which
these
various
issues
can
all
be
discussed
at
the
same
time
in
the
same
room
is
important
because
trying
to
tackle
them
one
at
a
time,
I
don't
think
leads
to
the
kind
of
solution
that
we
ultimately
will
need
the
sec.
H
E
So
we
documented
all
engineering
efforts
to
to
to
to
to
extend
the
addressing
model
and,
as
colin
pointed
out-
and
you
can
check
it
on
the
documents-
there
are
not
that
many
research
paper
as
a
reference,
so
we
don't
feel
like
that
that
there
must
we
don't
feel.
But
again
it's
it's
not
been
to
decide.
We
don't
feel
that
building
a
new
rg
is
worth
it
also
because
part
of
the
the
the
things
we
cover
in
the
documents
are
covered
by
existing
research
group.
F
M
This
is
dino,
so
discussion
is
good.
I
agree
it's
helpful
especially
face
to
face,
but
you
know
at
some
point
discuss
you
can
discuss
the
depth
and
there's
no
progress.
What
I
would
suggest
in
the
discussions
is:
maybe
we
see
without
out
of
the
list
of
problems
or
potential
problems.
Let's
see
what
people
think
about.
What's
the
most
important
single
problem
to
solve
like
what
address
like
what
address
problem
what's
wrong
with
ip
addressing
and
everybody
has
their
favorite.
E
M
All
right,
somebody
could
say
I
love
ip
addressing,
but
the
way
we
do
proxy
aggregation
in
bgp
is
a
problem.
Maybe
we
should
work
on
this
problem
because
we
think
it's
going
to
help
service
providers.
So
that's
what
I
would
suggest
is
pick
one
problem
and
then
we
could
focus
and
then
it's
succinct
and
it's
described
and
then
we
then
we
could
then
explore
exclu
solutions
that
either
change
something
or
extend
it.
I
know
changes
you
know
and,
like
you
said,
an
important
requirement
is
compatibility.
M
E
K
Actually,
I
think
dino
probably
articulated
it
better
than
I
could,
but
but
when
focusing
or
if
focusing
on
particular
issues,
I
really
want
to
see
more
about
what
problems
you're
trying
to
solve
specifically
right.
So
that's
something
that's
quite
quite
weak
in
the
document
it's
kind
of
all
over
the
place,
but
a
lot
of
people
have
said
that
already.
K
The
other
thing,
I
would
just
say,
is
just
a
sort
of
caution
about
thinking
about
developing
things
that
are
too
complex
going
forward,
so
we're
seeing
quite
a
lot
of
protocol
developments
that
are
quite
wide
ranging
at
the
moment-
and
I
would
say
you
know
if
you're
thinking
about
these
specific
solutions
really
have
a
one
problem
and
one
solution
kind
of
thing.
So
that's
just
my
feedback.
Thank
you.
Please,.
E
E
Thank
you
yeah.
I
do
agree
with
the
comment.
What
can
I
say
there
is
one
thing
I
personally
want
to
add.
I
mean
there
is
nothing
that
is
going
to
break.
We
see
that
just
there
are
in
several
places,
extensions
that
are
developed
in
a
kind
of
independent
way.
The
point
is
that
just
can
we
have
something
more
coherent
and
bring
it
together.
So
we
have,
we
have
time
to
discuss
and
we
have
time
to
make
the
right
choices.
I
mean
we
don't
are
in
a
hurry,
so
yes
scope
the
problem.
E
M
M
That
then,
could
be
solved
because
you
have
a
firm
problem
statement
and
a
solution,
and
so
you
know
I
mean
I
I
always
use
rsvp
as
an
example.
We
needed
a
reservation
protocol
on
the
internet
right
and
so
rsvp
was
developed.
It
was
done
in
research
in
university
and
it
did
solve
the
problem.
It
had
limited
deployment,
but
then
it
turns
out
that
sometime
later
people
said,
hey,
rsvp
might
be
a
good
protocol
to
do
label
binding
in
mpls
and
there's
more
deployment
of
than
there
is
for
the
original
problem
statement.
M
E
E
D
I
N
N
N
In
this
document
we
introduce
a
mechanism
that
can
access
the
local
services
in
diamonds
directly
without
the
dns
procedure.
By
using
a
special
special
address
in
the
picture,
we
can
see
that
when
the
ue
want
to
access
the
local
service,
they
it
will
send
since
two
attempt
time
one
is
a
normal
dns
square
to
get
the
service
id,
such
as
the
www
point,
local
weather
point
com
and
the
second
attempt
is
to
make
a
destination
of
ap
address
itself
by
hashing.
The
domain
name
bypass
the
dns
procedure.
N
N
N
N
Please,
thank
you.
This
is
about
the
section
four.
We
analysis
the
requirement
of
service
routine
next
workouts
in
the
mec.
The
network
need
need
to
support
forwarding
of
the
services
routine
ip
and
in
the
content
server.
They
should
support
the
binding
of
the
service
routing
ib
under
the
traditional
destination
address
ip.
N
N
N
This
is
the
service
routine
for
fixed
accounts.
Mmc
can
also
support
accessing
fixed
clients.
In
this
situation
we
also
have
a
gateway,
the
broadband
network
getaway
at
the
gateway
or
client
that
can
work
similarly
to
the
upf,
but
we
can
see
that
a
tunnel
between
the
png
and
the
imec
may
be
needed,
because
the
upf
pipes,
the
the
png,
is
not
in
the
imac
and
the
I
mean
thc
prefix
can
be
obtained
in
the
procedure
or
authentication
of
the
client
by
the
png.
N
We
also
think
about
that.
Perhaps
several
mic
may
connect
with
the
bngs
so
ability
to
make
a
decision
about
which
I'm
easy
to
connect
in
this
situation.
They
will
also
think
the
client
will
also
send
two
attempts
and,
if
the
time
to
success,
it
will
get
access
to
a
service
more
quickly
and
next
page.
Please,
oh
that's
all.
Thank
you
thanks
for
listening
and
welcome
for
comments
and
contributions,
any
questions.
D
O
You,
okay
hi,
I'm
donald
eastlake
with
future
way
technologies.
I'm
going
to
talk
about
revision
to
rsc
7042,
which
talks
about
iana
considerations,
ietf
protocol
and
documentation
usage
for
ieee
802
parameters.
Next
slide,
please
so
it's!
This
is
part
of
a
series
of
bcps
have
been
two
or
three
before
and
basically
there's
enough
changes
in
the
document
seems
to
be
generally
better
to
replace
it,
rather
than
try
to
do
a
bunch
of
updates
that
people
have
to
correlate.
O
O
So,
by
virtue
of
having
that
organizationally
unique
identifier,
iana
has
the
right
to
assign
mac
addresses
that
begin
with
that,
either
with
or
without
the
multicast
bid
on,
which
is
the
bottom
bit
of
the
first
byte.
The
way
ietf
writes
things,
so
those
are
the
ranges
that
are
shown
here
on
this.
This
slide
they're,
both
48
and
64-bit
mac
addresses,
if
you're
wondering
what
uses
64-bit
mac
addresses
the
three
uses.
I'm
aware
of
are
802.154,
which
is
zigbee,
firewires,
ieee,
1394
and
infiniband.
O
O
It
used
to
be
that
any
etf
working
group
could
ask
for
an
ether
type
from
the
ieee
registration
authority.
Those
requests
have
to
go
through
the
iesg.
Now,
I'm
not
sure
if
the
ieg
would
want
their
statement
in
this
document.
But
when
came
when
it
goes
through
the
iesc,
I
guess
we'll
find
out
or
it'll
be
found
out
next
slide.
Please.
O
O
However,
it
sometimes
makes
sense
to
allocate
very
large
blocks
of
mac
addresses
example:
ipv4
multicast
uses,
half
of
all
of
the
available
multicast
48-bit
mac
addresses
under
the
iana
oui
and
mpls
multicast
uses
1
8
of
them
so
anyway,
for
a
small
to
medium-sized
blocks.
There's
this
designated
expert
actually
has
two
couple
of
them:
I'm
the
primary
and
there's
a
secondary
that
can
disapprove
or
disapprove
it.
If
you
want
a
really
big
block,
then
the
isg
gets
involved
to
eradify
approval.
If
the
designated
expert
approves
it
the
way
it's
currently
written.
O
O
So
the
the
m
bit
there
is
the
multicast
bit
and
that's
still
unchanged
from
before.
If
it's
zero,
it's
unicast,
if
it's
one,
it's
multicast,
and
it's
also
one
of
course,
if
it's
broadcast,
which
is
all
bits
on
there's
this
x
bit,
which
is
formerly
the
local
bit,
and
if
it
was
zero,
it
meant
it's
a
global,
unique
address
which
is
still
true
and
it
used
to
be.
It
was
a
one.
O
It
meant
just
meant
local
and
means
the
local
network
administrator
had
control
over
things,
but
it's
been
renamed
x
and
there's
a
couple
more
bits
that
now
have
effect
because
for
various
reasons
I'll
get
into,
they
decided
that
the
local
address
space
should
be
divided
into
four
quadrants
with,
and
this
is
actually
an
optional
split
right
now.
But
it's
the
way
things
are
going,
so
I
think
it'll
become
somewhat
less
optional
in
the
future.
O
Next
slide,
so
here
we
go.
This
is
what
the
four
quadrants
are
with
the
x
bit
of
one.
The
next
two
bits
above
that
are
zero:
zero.
It's
just
like
current
local
up
to
the
network,
local
network
administrator
zero
one
is
assigned
to
a
cid
holder
I'll,
explain
that
in
a
sec
one
zero,
just
sort
of
reserved,
obviously
local
network
administrator,
can
use
that.
O
But
you
who
knows
they
sort
of
reserve
the
right
to
assign
some
other
use
for
that
quadrant
and
one
one
is
standard
assigned
which
is
intended
to
be
assigned
by
a
local,
dynamic
mac
address
allocation
protocol,
and
this
is
basically
to
answer
the
need,
because
of
virtual
machines
and
because
of
internet
of
things
devices,
both
of
which
can
be
quite
numerous
and
dynamic.
It's
a
violation
of
the
rules
to
use
these
globally
unique
mac
addresses
for
that
sort
of
thing,
so
you
just
wanted
some
protocol
to
assign
them
locally
and
dynamically.
O
So
I
there's
no
reason
for
any
this
to
be
exclusively
any
particular
protocol
from
any
particular
organization.
Ieee
has
82.1
cq,
there's
a
couple
rfcs
on
how
to
do
this.
So
looking
back
at
what?
What
exactly
is
this
oui,
so
uis
are
represent
organizations
they're
24
bits,
they
have
the
m
bit
0
and
the
x
bit
0..
So
that's
great,
and
if
you
have
an
oui,
you
automatically
have
the
right
to
assign
a
bunch
of
unicast
and
multicast
globally
unique
mac
addresses.
O
So
there
are
people
who
need
a
company
identification,
but
they
don't
really
need
necessarily
this
block
of
globally
unique
mac
addresses.
So
that
was
the
idea
of
the
cid.
So
it
has
the
local,
the
x
bit
a
one
and
the
y
bit
of
one
z
bit
of
zero,
and
that
basically
indicates
that
it's,
the
top
24
bits
are
a
company
identifier,
and
if
this
structured
local
address
plan
is
in
use
on
the
local
network,
then
you
also
have
mac
addresses
you
can
allocate
locally.
O
So
those
have
all
these
m
x,
y
and
z,
bits
of
one
and
the
multicast
bit
is
meaningless
for
the
use
that
it
was
originally
intended
for
so
that's
use
that
that's
been
deprecated
and
the
only
other
funny
thing
is
interesting
is
that
ipv6
multicast
has
always
been
defined
to
use
mac
addresses
with
the
top
byte
being
33,
which
actually
falls
into
this
administratively
assigned
quadrant,
and
it's
interesting.
I
if
I
mention
this
to
some
people
in
802
who
have
never
heard
of
this.
They
say,
that's
terrible.
O
O
So
there's
also
some
stuff
in
here.
It
adds
some
documentation.
An
example
code
points
where
there
weren't
before
the
two
rfc
sites
cited.
There
are
just
rfcs
that
explain
why
it's
a
good
idea
to
have
documentation
an
example
code
points
and
there's
you
know
it's
just
it's
a
the
various
clarifications
in
in
the
document
and
some
minor
changes
from
before
that
I
didn't
get
to
here.
I
recommend
you
take
a
look
at
it
if
you're
interested
in
this
sort
of
thing,
so
you
can,
you
can
see.
What's
there
next
slide.