►
From YouTube: IETF-RAW-20220701-1500
Description
RAW meeting session at IETF
2022/07/01 1500
https://datatracker.ietf.org/meeting//proceedings/
C
B
A
A
That's
coming
up
in
philadelphia
and
it's
too
bad.
We
won't
see
you
in
person
pascal.
This
is
it'll,
be
my
first
work-related
trip
in
person
since
covet.
So
I
was
I'm
very
much
looking
forward
to
it
and
hope
I
will
see
some
others
of
you
there,
but
I
think
I
will
hand
over
to
you
pascal
to
see
you
know
to
kind
of
hear
what
your
assessment
is
and
and
then
ask
others
who
have
come
to
join
the
meeting
as
well.
A
D
B
F
C
A
A
A
B
A
B
A
B
A
I
did
send
out
some
email
to
both
of
them
yesterday
saying
if
you're
not
going
to
attend,
are
you
do
you
have
some
thoughts
to
share
for
the
conversation,
but
I
think
they
are
happily
on
vacation
and
not
reading
their
email,
which
is
what
everyone
should
be
doing,
I
suppose,
but
when
they're
on
vacation,
but
it
leaves
this
this
meeting
a
little
hollow
to
say
the
least.
The
the
other
point
is
that
we
did.
A
F
Yeah
this
is
carlos
again,
I'm
not
sure
exactly
what
lou
had
in
mind
about
the
comments.
But
from
my
side
I
think
that
the
document
is
quite
okay,
but
I
I
will
appreciate,
maybe
a
bit
but
that's
a
personal
opinion,
a
bit
more
details
on
examples-
maybe
maybe
maybe
having
an
appendix
or
something
like
that
and
annex
with
some
examples
of
how
the
architecture
could
look
like
and
also
the
role
of
the
psc
and
the
difference
between
the
pse
one
is
distributed.
Pse
one
is
a
kind
of
more
centralized
one.
B
So
it's
a
double-edged
sword.
Yes,
people
might
understand
better,
but
at
the
same
time
they
might
limit
their
the
the
understanding
of
the
scope
of
the
architecture,
to
something
that
that's
just
but
now
producing
the
work
that
you're
talking
about
makes
a
lot
of
sense.
To
me,
I
just
I'm
just
not
100
sure.
I
belong
to
the
architecture
documents
specifically.
F
B
The
way
we
define
this
is,
we
said
the
architecture
is,
is
kind
of
something
we
propose
at
the
start,
and
that
gives
us
kind
of
the
scope
of
our
activity
and
the
framework
is
published
at
the
end
and
provides
the
how
to
to
achieve
the
architecture,
at
least
in
the
domains
that
we'll
support.
So
it
might
be
that
we
would
package
what
you're
talking
about
in
the
framework
and
saying
you
know
if
you
want
to
do
this
use
case,
use
the
framework
this
way
it
could
be
at
the
level
of
the
architecture.
B
It
might
be
that
it's
too
early
and
too
vague
to
to
really
apply
it
square
and
fair
and
square
when
you
do
it
with
the
framework.
You
know
it's
use
this
rfc
this
way
this
rfc
this
way
and
package
them
this
way
and
and
then
you
get
the
result,
a
at
the
level
of
the
architecture.
It
seems
much
harder.
So
I'm
just
trying
you're
thinking
out
loud
here,
but
when
we've
done
the
work,
we'll
be
a
lot
more
specific
on
how
you
can
achieve
a
particular
scenario
makes
sense
makes
no
sense.
I.
B
That
would
be
great,
and
actually
there
is
a
section
where
we
say
we
have
two
major
use
cases.
One
of
them
has
a
mesh,
that's
where
we
have
the
multi-harp
and
the
little
overlay
between
source
and
destination
where
we
want
determinism,
and
the
other
use
case
is
when
we
just
focus
on
the
access
like
you've
got
this
phone,
which
has
5g
wi-fi
multiple
interfaces,
and
you
want
to
know
if
you
should
use
one
of
the
interfaces,
a
collection
of
a
sub
collection
of
the
interface
etc
to
to
achieve.
B
F
To
have
like
a
bit
more
discussion
because-
and
this
is
related
to
the
multi-domain
thing
I
mentioned-
that
I
I
foresee
in
the
future
that
we-
we
will
have
not
purely
wired
or
purely
wireless
scenarios,
where
we
want
to
provide
some
determination,
reliability.
So
for
me
it
would
be
good
to
understand
how
we
foresee
that
to
work.
If
we
have.
G
Actually,
hi
everyone,
I'm
speaking
like
hearing
a
little
bit
the
interworking
of
pro
and
deafness
like
just
this
phrase,
was
a
bit
of
a
surprise
for
me,
because
I
fully
agree
on
the
heterogeneous
domains
and
so
on.
That's
what
we
are
after,
but
when
we
were
discussing
the
chartering
of
raw
at
least
my
takeaway
was
that
raw
is
an
extension
of
that
net
towards
wireless.
G
So
if
we
do
a
good
job,
then
there
is
no
need
to
figure
out.
Interworking
like
it
is
at
some
point
it
was
discussing.
This
work
should
be
done
in
that
net
or
not-
and
at
least
that
was
my
takeaway
from
the
chartering
that
rho
is
a
sort
of
a
wireless
extension
wireless,
specific
aspects
defined
for
the
base
defined
by
deathnet.
G
A
B
C
B
Would
not
work
for
a
wire,
I
mean
it's
just
an
interface,
it's
just
a
better
interface,
and
probably
if
you
have,
if
you
have
wire,
there
will
be
less
use
of
the
wireless
and
as
much
as
possible.
The
wire
will
be
used.
But
if
somebody
walks
on
the
wire,
you
know
catch
the
wire
and
not
tell
me
it
does
not
happen,
then
then
the
wireless
will
be
there
and
then
you'll
you'll
maintain
the
quality,
because
you
might
choose
one
two:
three
wireless
interfaces.
B
In
parallel
to
ensure
you,
you
maintain
your
your
delivery,
so
I'm
completely
in
agreement
with
both
carlos
and
janos,
and
I
don't
think
what
they
said
is
opposed
right.
I
think
that
they
also
agree
with
one
another
from
what
I
understand.
So
we
are
on
the
same
page
now
that
to
carlos
point,
does
the
architecture
reflect
that?
B
B
Because,
basically,
this
use
case
was
listed
to
us
at
the
beginning
when
we
started
this
group
and
started
working
on
this.
The
access
of
the
excess
use
case
was
not
really
there,
but
when
we
talked
to
people
that
that
they
always
came
back
with
this
use
case,
I
mean
the
foremost
use
case
is:
should
I
use
2y2
wi-fi
one
wi-fi
one
5g
25g,
I
mean
what
should
I
use
at
this
mode
and
yes,
the
psc
can
resolve
that.
B
B
Okay,
and
in
that
use
case,
basically
a
row
monitors
the
first
hop,
which
is
the
wired
wireless
access,
but
we
care
about
the
end-to-end
delivery,
and
so
basically
we
say
the
the
the
most
of
the
time,
the
the
failing
chain.
Now,
the
the
this
capable
element
is
the
first
half
it's
the
wireless,
so
we
attribute
any
delay
euro
to
the
wireless,
even
if
it's
not
the
case,
but
since
you're
not
that
net
end
to
end,
you
cannot
guarantee.
E
B
The
first
use
case
the
one
we
came
up
with
when
we
started
this
work
right.
We
say
we
have.
We
have
this
big
thing
and,
and
then
inside
there
is
this
little
mesh,
which
is
the
sort
of
mesh
that
raw
is
building
right
now
with
the
dow
projection
work,
and
in
that
case
we
are
the
net
end
to
end,
and
we
fully
should
obey
the
net
architecture.
B
Now,
in
the
case
where
we
only
monitor
the
access
at
layer
2
but
pay
the
price
for
ipn
to
end,
we
are
not
that
net
end-to-end
because
we
basically
use
the
psc
just
to
to
decide
which
access
link
is
going
to
be
used,
and
in
that
use
case
yeah.
We
cannot.
We
don't
obey
the
thing
that
we
granted
the
latency
and
we
are
that
net
all
the
way
through
because
we
are
not.
B
F
So
if
I
may
just
I
I'm
in
angry
with
what
pascal
said
and
just
to
come
to
to
just
provide
a
comment
on
the
integration
or
interoperability
point.
I
I'm
not
saying
just
to
clarify
also
to
janus
that
what
row
is
doing
is
not
compatible.
I'm
just
saying
that
I
think
it's.
It
will
be
useful
to
have
documented
somewhere
how
this
interpretability
is
achieved.
A
H
I'm
not
sure
that
I'm
comfortable
with
the
end-to-end
terminology,
because
that
reminds
me
the
discussion
we
had
in
discussing
itf
network
slides.
So
the
itf
network
slice
is
a
construct
to
provide
the
transport
network.
Connectivity
for
5g,
network,
slides
and
5g
does
not
use
end-to-end
either,
but
it
looks
at
it
as
a
5g
network
slice
is
a
covers
access
network
and
core
network.
H
H
B
Greg,
if
I
may
answer,
that's
perfectly
fine
with
me
the
way
you're
describing
it
so
just
two
two
remarks:
one
is
you
can
deploy
that
net
between
you
know
the
phone,
the
access
and
across
the
5g
core
and
beyond
the
5g
core
I
mean
it's
whatever
the
internet
is,
but
then
that
net
provides
only
the
guarantees
you
know
between
the
device
and
the
exit
of
the
5g
core.
So
that's
that's
perfectly.
Okay.
That
net
covers
from
an
entry
point
to
an
exit
point.
B
You
can
also
say
row
does
the
distribution
on
the
device
with
the
pse
and
then,
if
you
decide
to
use
5g
miracle,
you
know
the
the
packet
will
have
all
the
the
guarantees
all
the
way
through
the
car
as
well,
and
that's
that's
neat,
it's
row
from
the
first
hop
and
then
that
net
inside
the
core
and
then
whatever
at
the
end.
So
then
again,
since
it's
not
that
end
to
end,
we
don't
have
latency
warranties.
B
It's
just
just.
My
observation
is
the
way
we
describe
it
in
the
architecture
and
the
framework
is
completely
compatible
with
what
you
say.
It's
not.
There
is
no
position
in
my
mind.
We
basically
say
hey
we
monitor
when
we
can.
You
know
whatever.
If
we
can
ping
or
something
to
any
on
on
the
or
get
any
radio
information
on
the
first
half.
We
leverage
that
and
then
we
we
observe-
and
that's
really
am-
and
that's
really
your
work.
B
We
observe
the
end
to
end
ip
and
if
effectively
you
go
through
a
very
reliable
5g
slice
and
if
the
rest
after
you
know
the
rest
of
the
internet
is
nothing
pretty
much.
Nothing
then
effectively
will
get
a
very
good
result
in
this
oam
and
the
psc
will
certainly
favor
that
that
particular
interface
as
being
very
reliable
and
working
very
well,
but
will
not
observe
what
goes
in
the
call.
B
The
call
will
be
transparent,
we'll
just
observe
that
between
the
the
station,
the
user
equipment
or
whatever
and
the
server
we,
we
have
a
good
end-to-end
reliability,
because
we
cannot
observe
the
individual
ops
that
that's
what
we
say
in
that
use
case.
We,
if
we
can,
we
observe
the
first
half
whatever
we
can
gather
us
information,
the
first
top,
but
anyway,
what
we
care
about
is
this
layer,
three
oam
between
the
source
and
the
destination
we
get
whatever
whether
what
we
send
on
that
particular
path
works
or
not
versus
the
rest.
B
So
but
but
the
difference
is
in
the
in
the
mesh
case,
we
effectively
will
use
oam
at
each
hub.
We
will
observe
everything
and
we'll
get
a
much
finer
observation
of
which
path
of
sub-path
we
can
take.
For
instance,
in
the
mesh
case
you
can
decide
to
use
the
top
path
and
then
go
to
the
bottom
path
and
finish
with
the
bottom
path.
Just
because
there
is,
there
is
an
error
in
some
links
somewhere
along
the
the
end
of
the
top
path.
That's
not
the
sort
of
thing
you
can
do
with
the
access
use
case.
B
A
H
To
be
provided
by
the
components,
because
if
we
disaggregate
their
network
slice
or
the
service,
so
we
can
monitor
end
to
end
and
the
same
time
as
described
in
the
mesh.
We
can
monitor
and
optimize
each
hub,
and
there
are
several
questions
here-
that
I'm
very
much
interested
in
exploring
and
discussing.
B
What
I
like
in
the
way
you
you
discussed
it
is,
we
can
see
two
use
cases.
One
of
them
is,
is
raw
kind
of
over
that
net,
meaning
that
you
have
all
the
that
net
support
in
every
every
hops
and
that's
the
mesh
case
and
that
net
has
new
services.
On
top
of
that,
and
that's
the
pse
right.
So
that's
that's
one
use
case,
and
the
other
use
case
is
that
net
on
a
certain
part
of
the
way
and
raw
basically
has
a
front
end
to
it.
B
So
you
you
manage
the
access
with
row
and
once
the
access
is
passed,
this
net,
that
net
takes
over
and
and
for
row,
it's
it's
finished,
it's
just
so
these
are.
This
is
more
like
the
access
case
and
and
so
it
kind
of
matches
what
we
have
in
mind.
But
on
the
other
hand,
I'm
just
wondering
if
we
describe
enough
of
that
in
the
architecture
we
need
to
stay
high
level,
but,
for
instance,
what
you
say
about
additive
metrics
and
these
aggregated
basically
functions.
B
Should
we
put
more
text
in
the
architecture
about
this?
Would
you
have
some
suggestion
because
for
this
call
that's
what
we
are
after,
we
are
saying
hey.
We
need
to
publish
the
architecture,
so
we
can
start
the
work
and
the
architecture
should
basically
give
us.
You
know
the
kind
of
the
format
in
which
we're
working
and
the
terms
and
and
the
functions
that
we
need
to
to
provide,
etc.
So
we
discuss
oam,
but
do
we
do
it
in
enough
detail
and
not
too
much
detail?
That's
always
the
problem.
B
We
need
to
to
leave
room
for
the
work,
so
we
cannot
impose
everything
at
the
architectural
level
it's
vague
enough,
but
on
the
other
hand,
if
there
are
important
architectural
concepts
like
this
disaggregation,
it
should
be
cited.
So
you
see
what
I'm
after
I
mean
what
they
said
in
that
email
is.
There
are
topics
like
layer,
2,
matrix
layer,
2
information,
and
I
was
thinking
about
lu
really
because
he
knows
dilip,
you
know
and
the
way
it
works.
B
Cetera
so
but
but
yes,
oem
is
the
other
very,
very,
very
critical
thing
and
we
have
a
high-level
description
of
who
I
am,
but
if
you
could
in
your
review
of
the
architecture
before
we
publish
or
even
before
you
know,
the
group
call
look
at
it
and
see
if
what
you've
said
can
be
covered
within
the
architecture
is
not
described
enough
and
should
be
described.
I
mean
I
would
really
appreciate
that
feedback,
because
away
any
component
in
this
would
can.
A
B
A
B
Basically,
getting
since
really
greg
is
the
expert
getting
feedback
on
how
much
oem
we
cover
and
the
real
architecture
of,
am
you
know
whether
you
do
it
in
band
etc?
That
needs
to
be
covered
and
the
concept
of
segregation
is
not
covered,
and
I
was
wondering
if
we
should
mention
it
and
have
some
text
about
it.
That
was
my
question.
I
A
A
B
A
A
B
B
And
so
you
we
need
to
have
this
third
use
case
in
mind.
I
completely
agree.
The
question
is:
what
of
this
discussion
impacts
the
architecture
what's
missing
in
the
architecture
and
and
the
thing
for
me
that
I
heard
that
three
missing
in
the
architecture
and
then
the
framework?
Certainly
we
can
have
more
stuff,
but
in
the
architecture
it
was
more
the
the
points
that
greg
made
about
basically
kind
of
can
do
we
do
row
over
that
net
or
row
first
and
then
that
nut
and
th.
B
B
B
Do
we
talk
enough
about
responsibilities
and
objects
and
components,
and
maybe
we
need
to
have
you
know
names
associated
to
components,
doing
this
thing
and
that
thing
and
and
if
we
need
that,
then
that
should
be
in
the
architecture
and
that's
missing,
because
we
don't
go
to
that
detail
in
the
net
architecture.
We
do
right.
B
We,
if
you
look
at
this,
we
talk
about
the
service
layer
and
we
say
you
do
this
thing,
those
things
and
you
have
the
bus
stack
to
send
out
the
receiver-
and
you
say,
oh
here,
you're
doing
at
this
level,
you're
doing
replication,
elimination
and
this
layer
you're
doing
forwarding.
Whatever
I
mean
this
is
described
and
it
makes
sense,
it
belongs
to
the
architecture.
H
Additional
complementary
set
of
documents,
so
we
are
finalizing
that
net
oem
framework
and
we
have
two
more
documents
that
analyze
that
net
over
ip
and
that
net
over
mpls
oem
specific
aspects.
So
if
we
look,
if
I,
when
I
look
at
a
raw
architecture
document,
I
think
it
sufficiently
covers
oem
issue,
and
so
it
can
progress
if
we
feel
that
there
are
more
things
that
we
need
to
discuss
in
regard
to
oem
aspects
in
raw
or
in
some
use
cases.
B
B
So
if
that's
so,
if
the
oam
is
is
probably
good
enough,
then
we
are
back
to
the
original
question
I
mean.
What
specifically,
are
we
needing
in
this
document
to
go
work
or
plus
call?
So
I
still
I
still
in
I
have
this
to
do
on
showing
that
net
and
and
row
either
row
over
that
net
in
the
mesh
case
or
row
first
and
that
net
second,
in
the
access
case,
where
that
net
covers
the
core
and
draw
the
access.
B
So
this
is
a
nice
picture
that
you
can
draw
and
explain
it's
beyond
the
use
case,
because
it's
beyond
the
framework,
because
here
you're
talking
about
what
kind
of
service
you
do
end-to-end
and
how
the
functions
are
separated.
So
it's
this
is
architecture,
and
we
we
need
it
with
that.
I
mean
if
and
that's
that's
the
ball
in
your
hands
now.
B
Oem
docs
and
we
will
effectively
explain
how
they
work
in
the
framework
now
and,
and
it
is,
it
has
started
effectively
so
so
this
is
very
compatible.
I
mean
we
are
on
the
same
page,
that's
really
really
cool.
Now
the
question
remains:
when
do
we
publish
the
architecture?
When
do
we
do
last
call
I
understand
that
lou
is
not
with
us,
so
we
will
need
his
his
feedback.
A
B
A
A
G
A
B
I
agree
I
mean
we,
we
have
the
next
meeting
where
hopefully
lou
will
give
us
inputs.
Then
we
will
have
to
to
earn
all
those
inputs.
The
prime
is
probably
it
was
going
to
be
too
late
to
publish
anything
before
ietf,
so
there
will
not
be
a
document
with
all
those
inputs
inside
before
itf.
That
cannot
be
so
there
is,
we
don't
even
have
the
document
ready
to
start.
Our
group
last
call
you
know
at
the
etf
unless
we
can
publish
you
know
on
monday
or
something
of
the
atf.
B
So
so
it's
completely
a
strange
goal
to
start
it
right
after
the
atf.
That
is
already
a
very
strange
call,
and
I
I
agree
with
you.
I
don't
believe
that,
after
that
you
know
it's
it's
august,
many
people
are
in
vacation,
so
the
best
can
do
is
probably
september,
and
since
even
some
people
are
in
vacations,
it
would
probably
be
all
the
month
of
september,
something
like
that
has
to
make
sure
left
time
and
that's
the
way.
I
see
it.
That's
really
the
best
can
do
yeah.
It
seems
pragmatic,
realistic.
A
I
A
D
A
That's
wonderful
to
hear,
I
think
it's
going
to
pave
the
way
as
our
first.
Yes,
our
first
document
and
we're
really
pleased
with
the
quality
of
the
document
and
the
rigor
with
which
everybody
involved
has
answered
each
and
every
detailed
and
question
and
minutiae.
It's
really
and
it's
been
very
educational.
Also,
given
the
timing
of
you
know
that
this
document
precedes
a
document
that
really
describes
how
the
technology
works
over
ip.
So
that's
been.