►
From YouTube: DETNET WG Interim Meeting, 2020-06-11
Description
DETNET WG Interim Meeting, 2020-06-11
A
A
I'm
Lou
Berger,
we
have
the
honors
Farkas
also
online
Ethan
sends
his
regrets.
He's
unable
to
be
here,
I
put
into
the
chat
session
a
link
to
the
virtual
blue
sheets.
It
is
on
etherpad,
please
make
sure
you
go
there
and
put
your
name
at
the
end.
Also,
please
stay
there
once
you
do
that
and
help
us
capture.
What's
discussed.
A
As
always,
you
know
this
is
an
informal
IETF
meeting,
which
means
we
have.
Our
note
well,
which
covers,
are
anything
that's
said
here
becomes
part
of
our
record.
We
are
recording
this
call.
Although
I
don't
see
the
record
there,
it
is
it's
a
in
the
upper
right.
It
should
say
that
we're
recording
and
so
everything
we
say
is
covered
by
our
know.
Well
and
I
are
our
IPR
process.
A
So
you'll
see
an
occasional
reminder
from
the
chairs
to
go
to
the
blue
sheet,
but
everything
else
we
should
just
use,
plus
Q
minus
Q
to
enter
the
queue
and
to
leave
the
queue
and
we'll
call
on
you.
One
of
us
will
call
on
you
and
it's
what
it's
your
time
to
speak.
If
you're,
not
speaking,
please
meet
yourself,
looks
like
you
know,
everyone's
really
familiar
with
remote
at
this
point,
and
everyone's
already
done
that.
So
thank
you
so
much
so
I
said
the
blue
sheets
a
few
times.
A
A
So
one
of
the
discussions
we
thought
it'd
be
worth
having
with
the
list.
Is
this
how
we
continue
in
this
mode
because
it
seems
like
we're
gonna
be
in
this
mode
for
a
while
right,
where
no
announcement
has
well
one
way.
It
is
obviously
virtual.
That's
been
announced,
we've
all
seen
the
discussions
on
the
list
about
that.
109
is
still
TBD.
You
know
I'm
personally
skeptical
about
it.
Yeah
I'm
also
disappointed
but
I'm
skeptical
that
that
would
be
in
person,
but
even
if
it
isn't,
it
is
in
person.
A
We're
gonna
be
working
in
this
mode
for
a
while,
and
we
really
wanted
to
get
some
input
from
the
group
on
how
they
think
we
should
be
working
and
it's
clearly
a
challenge.
We've
seen
some
good
discussions
on
the
list,
we've
always
done,
you
know
had
the
list
as
part
of
our
formal
process
that
hasn't
changed,
we've
seen
a
fair
number
of
informal
meetings
and
we
certainly
support
that.
Those
types
of
informal
meetings
are
always
available
to
working
group
members.
A
The
chairs
are
can
set
up
the
working
group
WebEx
and
we
will
announce
any
of
those
meetings
to
the
list,
so
others
can
come
in
and
we
also
have
these
virtual
meetings
and
we're
doing
this.
What
we're
doing
here
right
now
is
an
example
of
frankly,
it's
a
lot
less
attended
than
an
in-person
meeting,
so
it's
not
clear
how
successful
these
virtual
meetings
will
be,
and
there
is
a
virtual
108
and
we
do.
We
have
put
in
a
meeting
request,
we're
interested
in
hearing
from
participants,
but
how
they
think
the
virtuals
are
going.
A
The
other
working
meetings,
the
virtual
this
virtual,
as
well
as
how
we
might
best
continue
in
during
this
time
or
we're
not
doing
in-person
meetings.
So
I
don't
see
people
jumping
in
the
queue,
but
here's
an
opportunity
to
chime
in.
If
you
have
something
you'd
like
to
comment
or
say,
if
not
we're,
also
happy
to
take
comments
on
the
list,
so
I'll
pause
for
a
moment
to
see
if
anyone
wants
to
jump
in
queue.
B
A
A
A
It's
an
important
topic.
Just
a
reminder,
do
have
an
IPR
process
where
we
formally
asked
for
disclosure
of
IPR
both
before
adoption
and
before
last
call
the
generally
people
are
responsive
on
that,
sometimes
not
so
much,
and
we
will
ask
for
explicit
responses
from
all
authors
and
listed
contributors
before
going
to
last
call
certainly
I
mean.
Excuse
me
before
going
to
publication
a
request
to
the
iesg.
A
Pre
off
of
the
the
replication
and
elimination
is
not
supported
in
the
current
draft.
I
think
the
list
accurately
reflects
multiple
people's
reading
of
the
the
document.
So
when
I
say
I
am
talking
as
an
individual,
you
know
as
a
because
I
am
also
a
contributor
in
this
document.
As
I
read
the
document.
A
The
specific
point:
that's
a
question
is:
is
that
a
really
node
you,
if
you
service
that
you
must
send
with
a
single
s
label
my
view
is
that's
a
simplification
that
was
taken
in
order
to
get
the
documents
done,
and
that
is
what
the
document
says.
We
could
pull
it
back
and
change
that
behavior
to
allow
relays
to
have
multiple
output
about
multiple
outgoing
s,
labels
for
the
for
the
same
service.
A
A
Hopefully,
we'll
see
if
anyone
jumps
in
the
queue
giving
people
a
moment,
I'll
mention
that
the
comment
that
was
made
by
balázs
on
the
list
is
is
that
you
can
support
a
particular
mode
of
protection
today,
but
it
requires
coordination
across
multiple
nodes
to
use
the
same
s
label
and
that
you
know
that
that's
a
compromise.
That's
certainly
a
compromise
position
and.
A
That's
where
the
working
group
ended
up
again.
If
the
working
group
wants
to
change
it,
it's
better
to
change
it
now
than
to
try
to
fix
it
later,
but
we're
also
not
seeing
people
putting
on
the
list
messages
to
saying:
let's
change
it.
Does
anyone
want
to
comment
on
this
before
we
move
on
it's
a
it's
important
topic.
C
However,
the
the
consequences
cut
using
as
Labor's
and
the
procedures
for
the
Aged,
node
and
relay
nodes.
They
are
not
formulated
on
that
part.
So
I
think
that
is
somewhat
confusing,
because
I
think
that
in
that
part
of
the
document
where
we
are
describing
the
procedures,
we
are
allowing
that
the
heat
or
what
was
commended
as
a
missing
behavior
I
think
during
learn.
D
A
A
D
Well,
I
I,
don't
have
a
strong
opinion
opinion
on
whether
we
should
pull
out
the
document
to
draft
from
the
acidity
evaluation
or
not.
But
the
my
position
is
that
the
either
a
telnet
MPLS
theta
plant
solution
does
not
mandate
the
use
of
the
same
value
in
all
all
the
edge
and
rellenos
associated
with
a
specific
service
over
the
whole
network.
So
if,
if
it
is
too
late
to
add
new
texture
to
the
draft
and
I
think
we
start
on
a
new
draft
which
addresses
this
issue
and
again
and
I
have
no
strong
opinion.
Okay,.
A
Thank
you
very
much.
The
the
draft
doesn't
require
the
same
label
everywhere.
The
the
particular
point
is
is
that
the
at
an
elimination,
point
elimination
uses
the
same
label
so
at
each
elimination
point
you
have
to
both
incoming
services
I'm.
Sorry,
both
the
incoming
forwarding
sub-layer
packets
have
to
come
in
with
the
same
the
same
s
label,
and
that
has
an
implication
that,
if
you're
doing
replication
at
multiple
places
that
they
have
to
each
of
those
replication
points
have
to
use
that
same
label.
A
Many
different
label
values
as
you
want,
but
that's
fundamentally,
the
question
is:
is
do
we
want
this
other
behavior
and
to
the
process
point
if
we
have
some
small
clarification,
texts
which
are
not
is
not
changing
behavior
and
it's
just
an
editorial
nature.
I,
don't
think
it's
too
late
to
put
those
in
and
without
doing
a
full
reset.
But
if
we
are
doing
a
change
in
the
in
the
behave
in
the
data
playing
behavior,
we
can
absolutely
have
to
bring
it
back
to
the
working
group.
A
E
Yes,
thinking
I
agree
with
the
Bosch
characterization,
so
it
appears
that
there
is
a
difference
interpretation,
but
what
my
question
is:
do
we
have
a
candidate
text
that
at
least
we
have
some
part
of
their
participants
of
the
discussion,
would
propose
to
put
or
put
in
the
document
or
replace
part
of
the
document,
because
if
we
pull
their
draft
now
and
realize
that
well
we
don't
have
an
agreement.
We
don't
have
anything
that
we
want
to
say
in
the
holiday.
The
document,
then,
what's
the
purpose
of
pulling
it
out.
A
A
A
A
So
at
the
end,
if
you
could
just
put
one
letter,
your
maybe
your
first
initial
or
last
initial,
if
you
like,
either
of
these
on
etherpad
and
again
I'll-
put
the
link
and
etherpad
sorry
they
like
to
etherpad
in
the
chat
window.
Please
go
there
now
and
if
you
have
an
opinion
put
which
one
you
prefer,
it
is
acceptable
to.
C
C
C
B
A
A
Well,
this
goes
to
the
clarification,
we'll
need
to
clarify
that
and
I
think
that
Greg
has
a
good
point,
we'll
have
to
clarify
that
on
the
list
and
if
there,
if
that
clarification,
leads
with
a
technical
disagreement
and
we
you
know,
we
may
still
end
up
sending
to
the
list.
The
back
so
Deborah
put
you
on
the
spot
with
respect
to
the
mpls
documents.
F
F
A
We
should
come
up
with
a
proposed
editorial
change
to
draft
DET
net
draft
IETF
DET
net
MPLS,
we're
circulated
on
the
list
and
then
at
that
time
visit
whether
revisit
whether
or
not
we're
doing
a
functionality,
change,
obviously
functionality
changes.
We
would
require
it
to
be
sent
back
to
the
working
group
so
from
iesg
situation,
I.
Think
of
the
the
data
plane
drafts
listed
on
this
slide.
A
We
have
five
of
them
that
are
with
the
IES
JD
I
believe
the
MPLS
ones
should
be
held
up,
which
means
that
the
first
two
listed
are
fully
ready
to
go,
but
the
MPLS
ones.
We
should
wait
until
we
get
this
clarification.
I
actually
don't
think
it'll
modify
the
last
two.
But
obviously,
if
the
base
document
isn't
there,
we
shouldn't
proceed
with
the
the
other
ones
that
are
dependent
on
it.
A
F
That's
clear:
hey
just
make
sure,
because
this
is
sort
of
a
new
rules.
Ihg.
Has
that
any
comments
from
any
of
the
area
director
reviews
you
need
to
respond
to
so
make
sure
whoever
is
holding
the
pen
for
those
two
documents
that
they
can
say
that
they've
been
responding
to.
Otherwise,
when
it
comes
up
on
the
teletrac
that
that
will
be
a
big
blocker,
because
they
will
say
that
and
you
don't
in
an
area
director
review,
you
don't
have
to
actually
change
something,
but
you
do
have
to
show
due
diligence
that
you
responded
to
it.
B
A
G
A
D
D
D
A
A
Okay,
so
the
last
topic
I
think
we
have
here
is
on
reach
our
Turing.
We
do
have
a
revised
charter
that
was
approved.
Thank
you
very
much
to
our
ID
Deborah
for
getting
that
done.
The
main
addition
is
bringing
in
controller
plain
definitions
and
documentation
that
was
previously
not
in
our
Charter.
It
now
is,
there's
also
been
some
minor
wording
editorial
pieces,
as
well
as
trying
to
align
with
where
things
have
shifted
in
working
groups
and
other
working
groups,
because
we
do
have
references.
Other
working
groups.
A
A
And
I
think
these
are
in
line
with
the
the
documents
that
we
have
in
flight.
With
the
exception
of
the
controller
playing
framework,
we
had
some
good
momentum
on
the
controller
plane
framework.
I
suspect
that
the
last
the
107
being
virtual
may
have
slowed
us
down
a
little
bit,
but
we
are
definitely
looking
to
adopt
the
document
that's
being
discussed
on
the
list.
There
are
there's
open
comments.
A
G
A
H
Yes,
thank
you
Andy
for
for
your
work
and
introducing
me
as
the
new
editor
for
the
draft,
and
maybe
I
noticed
that
there
were
some
comments
in
the
manliest
amount
of
draft.
Also,
maybe
some
conditions
from
the
working
group,
chair
and
I
will
be
working
on
this
in
the
following
days.
Hopefully
we
could
move
this
document
forth.
A
Yeah
from
a
chair
perspective,
it's
good
to
address
comments
that
were
sent
to
the
list.
I
think
he
did
send
some
comments,
but
I
think
they
were
sent
as
individual.
He
can
clarify,
but
no
matter
what
it's
it's
better
to
resolve
comments
before
we
go
into
adoption.
That's
then
have
comments
to
say
you
know
we
shouldn't
adopt
until
these
comments
or
address.
So
it's
better
just
to
get
them
addressed
before
trying
to.
B
A
H
H
A
Thank
you
all
right,
so
these
are.
This
is
on
the
data
tracker,
and
you
know
it's
a
if
anyone
has
comments
beyond
what
we've
talked
about
here
feel
free
to
send
them
to
the
list
are
as
a
reminder
as
I
mentioned
earlier.
Our
next
meeting
is
expected
to
be
at
108
the.
We
hope
that
you
know,
update
your
drafts
in
time
for
discussion
there
and
we'll
see
how
we
organize
that
meeting
based
on
the
slot
requests.
A
That's
up
which
is
TSN
below
if
I
think
you're
the
one
presenting
either
I
can
present
from
here
or
you
can
grab
the
screen
as
you
so
choose,
and
that's
if
you
want
to
present
from
your
from
your
own
screen,
please
feel
free
to
just
say:
that's
what
you're
gonna
do,
if
you
don't
know,
I
have
them
queued
up
here.
So
I.
C
Think
that
that
is
fine.
Thank
you
very
much.
So
this
is
just
a
summary
about
the
TSN
related.
That's
not
data
plane
drops
and
if
we
can
jump
to
the
next
slide,
it
is
just
highlighting
that
we
have
three
documents.
Two
of
them
is
dealing
with
scenarios
where
TSN
is
a
sub
network
in
a
dot.
Not
so
these
are
that
not
over
subnet
as
scenarios.
These
are
the
IP
over
TSM
and
MPLS
over
TSM
documents,
and
the
third
document
is
dealing
how
to
interconnect
TSN
Ethernet
networks
over
a
death
net
domain.
C
So
that
is
the
third
document.
Please
jump
to
the
next
slide.
It
is
just
providing
the
link
to
the
document,
so
we
can
skip
this
and
go
to
the
next
slide
and
in
the
slides,
I
will
update.
But
what
is
the
content
of
these
drafts
and
what
was
changed
before
uploading?
The
the
latest
version,
so
their
IP
over
TS
and
document
specified
the
deterministic
IP
data
plane
when
it
is
operating
over
a
TS
n
sub
network.
C
C
The
next
slide
is
summarizing,
practically
the
the
behavior
from
management
and
control
information
perspective.
What
you
have
to
provide.
We
have
defined
the
functionalities
for
a
TS
and
our
IP
data
node,
and
that
node
is
practically
member
of
both
the
ethnic
domain
and
the
TSM
sub
Network
and
within
the
TSM
sub
Network.
The
dotnet
node
behaves
like
a
TSN
aware,
talker
or
listener.
So
that
is
the
role,
but
it
must
fulfill
and,
of
course,
the
darknet
flow
related
parameters
and
identification.
They
must
be
converted
to
TSN
Stream,
IDs
and
stream
related
parameters.
C
Three
set
of
information
with
which
have
to
be
provided
in
order
to
configure
such
a
definite
IP
note
in
order
to
use
the
TSN
sub
network.
So
there
are
definite
IP
related
configuration
because
it
has
that
natural.
It
has
TSM
related
configuration
according
to
the
TSN
role,
but
that
node
has
in
the
inside
the
TSN
son
network
and
and
the
third
set
of
configuration
parameters
are
related
how
to
map
the
definite
IP
floors
and
the
TSN
streams.
C
C
We
have
taken
the
Service
protection
interworking
out
of
scope
in
the
document,
so
this
is
something
what
is
left
for
further
study.
That
means
that
service
resiliency
related
functionalities,
which
requiring
a
sequence
number.
They
are
TSN
and
MPLS
specific,
so
they
are
not
interacting
in
the
current
version
of
the
document.
It
is
also
summarizing
management
and
control
information,
and
the
security
section
was
also
updated
in
this
document,
and
the
next
slide
is
showing
also
the
management
and
control
information
stuff.
C
It
is
very
similar
from
structure
perspective
to
the
IP
scenario,
but
of
course,
here
we
are
speaking
about
MPLS
that
not
domain
an
MPLS
node.
It
is
acting
from
TSN
sub
network
perspective,
again
as
a
TSN
aware,
talker
and
listener
role,
and
we
have
to
map
the
MPLS
that
not
flows
to
the
TSN
streams.
So
we
here
we
have
also
very
similar
to
the
previous
IP
over
TSN
scenario.
3
set
of
information
for
configuration
1
is
related
to
the
definite
role
of
the
node.
C
The
other
is
related
to
the
TSM
role
of
the
dot
natal
pls
node
inside
the
TSN
sub
Network,
and
the
third
set
of
information
is
required
in
order
to
map
the
data
time.
Pls
hosted
TSM
streams,
so
these
were
the
two
documents
had
to
use
a
TSN
sub
network,
and
if
we
jump
to
the
next
slide,
it
will
show
the
scenario
of
that.
My
data
plane
is
used
to
interconnect
ESL
networks
over
there,
not
MPLS
Network.
C
Here.
The
concept
is
that
the
TSN
streams
are
treated
as
that
net
up
flow
at
the
edge
of
the
and
that
not
MPLS
Network,
that
not
domain
practically
behaves
like
big
TSM
relay
node
for
the
TSN
streams
and
the
ports
and
the
service
proxy
on
the
age
node
they
are
practically
can
be
treated
as
a
part
of
that
TSA
relay
node.
C
We
have
described
the
procedures
regarding
TSN
over
and
pls
scenario.
There
are
procedures
for
TSM
functionalities
at
net
service
trucks,
proxy
related
procedures.
This
is
the
functionality
which
is
mapping
the
TSM
streams
to
that
that
flows
than
the
darknet
service
and
forwarding
sub
layer
related
functionalities,
and
here
similarly
to
the
previous
document,
there
is
a
possibility
to
have
Service
protection
interworking,
but
this
is
something
that
is
for
further
study
and
not
covered
in
the
document.
C
C
So
this
is
about
the
three
documents
and
on
the
last
slide,
we
have
summarized
what
was
changed
since
in
the
last
revision.
So
there
were
editorial
updates,
abbreviations,
sexual
references,
clarification
typos.
They
were
corrected.
We
have
fixed
us,
the
conformance
language
to
to
have
it
fully
done.
We
have
updated
the
security
section
practically
based
on
the
lessons
we
have
learned
during
the
iesg
review
of
the
data
point
documents,
and
there
were
also
suffered
relieved
comments
which
were
updated
in
the
document.
So
we
have
made
all
these
changes,
and
this
is
where
we
are.
C
A
Iii
think
that's
agree,
I
think
that's
what
the
document
is
with
chair
or
Shepherd
hat
on
I
will
be
separating
these
documents.
The
I
would
save
address
sort
of
the
entry
by
entry
comments.
I
have
not
done
a
full
review.
You
know,
there's
a
normal
last
call
process
and
you
know
we're
gonna
follow
that,
but
I
do
think
the
documents
are
ready
for
last
call
and
I,
don't
see
a
reason
not
to
proceed
with
that
at
this
point.
A
A
E
Okay,
so
what
we'll
have
an
update,
David
agreed
to
join
as
a
golfer
and
to
the
material
of
the
document?
What
we
added
is
consideration
for
on-demand
I
am
using
ICMP
active
om
using
battement
and
UDP
encapsulations
aspects
of
mapping
active,
om
IPO
am
in
the
deadness
flows
and
active
I
am
using
GRE
and
UDP
encapsulation
next
slide.
Please.
E
What
we
have
when
we
discuss
epic,
oh
yeah,
according
to
classification
in
RFC
77
99
active
om,
is
the
OM
that
uses
specifically
constructed
test
probes
that
are
injected
in
the
network.
So
it's
well
familiar
to
us
ping
and
traceroute.
So
it's
the
ICMP
protocol
in
IP
or
it's
a
letter
to
link
trace
corrected
that
continuously
check.
That's
either
B
of
D
and
B
have
been
successfully
applied
to
different
encapsulation
side
e
MPLS
to
the
wires.
E
It's
a
little
bit
different,
so
we
often
use
the
terms
continuity
check
and
connectivity
verification
interchangeably,
which
they're
these
two
mechanisms
are
similar,
but
not
identical,
and
the
difference
is
that
continuity
check
is
verifies
that
there
is
a
path
between
our
endpoints,
so
a
packet
on
frame
can
be
be
delivered
from
ingress
to
egress
are
the
connectivity?
Verification
is
more
strict
because
it
real
differentiates
different
connections.
E
So,
let's
speak,
it
would
take
like
analogy
in
electric
wiring,
so
the
continuity
check
says:
ok.
Well,
there
is
a
way
how
the
electrons
get
from
on
to
the
device
and
doesn't
matter
whether
it
gets
on
blue
wire
or
on
the
red
wire.
Are
the
connectivity
verification
is
to
verify
that
electrons
get
on
a
wire
that
we
expect,
for
example,
so
there
should
be
a
blue
wire
and
no
electrons
from
the
red
wire
should
get
to
the
device.
E
E
E
E
Forget
that
it's
being
supported
by
the
separate
product
Oh
true,
it
might
be
realized
using
some
other
method
mechanisms,
because,
for
example,
there,
the
UDP
ping
anticipating,
but
the
most
commonly
used,
is
ICMP
and
it
uses
their
IP
protocol
similar
to
UDP
for
their
pinga
traceroute.
We
need
to
have
support
for
Qwest,
replied
and
a
certain
number
or
subset
of
error
messages
like
destination
unreachable
or
digital.
E
E
E
E
E
A
E
E
Active
OAM
in
the
IP
depth
and
flow,
so
the
critical
for
active,
OAM
being
useful
and
accurate
in
useful
in
fault,
management
and
tracing
the
path
and
accurate
in
performance
monitoring
is
sharing
so
that
test
probes
do
fade,
share
with
their
flow
being
monitored,
and
that
has
two
components.
The
first
is
coral
business,
in
other
words,
is
that
the
test
packet
traverses
the
same
links
and
nodes
in
the
network
as
their
flow
being
monitored.
E
E
There,
if
I,
am,
will
have
to
use
the
same
DCP
marking
as
that
net
or
it
has
to
be
a
map
to
that
night
corrupted
Ness
again,
we
can
imagine
how
it's
done
and
that
could
be
done
by
using
bat'leth
ACLs
and
effectively
that's
either
again.
It
could
be
a
black
magic
to
select
the
source
port
or
the
spraying
test,
packets
and
identifying
all
the
paths
being
taking,
and
then
correlating
this
information
with
information
that
we
have
on
that
net
flow,
that
already
being
pins
in
IP
network.
A
Again
as
a
individual,
the
I
think
you're
missing
here
that
you
can
also
control
the
treatment
on
the
network
through
the
control
plane,
unlike
unlike
a
typical
IP
network,
where
flows
are
routed
on
destinations,
we're
doing
cur
service,
we
allow
for
per
service
treat
traffic
treatment,
including
a
path
selection
via
the
controller
plane
and
I.
Think
you're
missing
this
here,
I'm
not
going
to
make
the
comment
again
presentation
I
can
take
it
offline
with
you.
If,
if
you'd
like.
E
Let's
take
it
to
the
list
and
then
we'll
look
into
how
that
achieved
for
the
dead
net
and
how
that
can
be
achieved
or
who
am
produções
I
said.
So
there
are
ways
of
doing
it
through
the
ACLs,
but
if
it
can
be
done
in
control,
plane
per
flow
third
protocol.
Because
again,
one
of
the
challenges
in
I
pianted
om
is
that
each
protocol
uses
its
own
well-known
destination,
UDP
port,
because
except
for
ICMP,
which
is
a
different
IP
protocol,
other
epic
OAM
are
they
use
UDP
transport
and
to
demultiplex
protocols,
now
used
destination
port.
E
C
E
C
E
E
A
A
A
As
a
time
check,
we,
we
actually
sort
of
internally
thought
we'd
end
up
with
45
minutes,
so
you're
pretty
close
to
that.
So
you
have
a
fair
bit
of
time
and
for
everyone
else
on
the
call.
This
is
the
last
topic
we
plan
to
discuss
and
so
we're
expecting
that
this
will
take
that
from
the
time
from
now
until
the
end,
however
long
that
goes
all
right,
she's
long
overdue.
Thank
you.
Okay,.
H
Okay
and
I
will
introduce
the
first
part
of
this
light
we
and
a
new
order.
Don't
he
join
our
work,
I
think
from
last
90
°f
and
he
does
a
lot
of
contribution
and
we
are
glad
to
see
that
now
we
have
210
a
young
models
and
during
this
period
of
this
period
of
time,
we
are
discussing
about
the
differences
of
these
two
than
young
models,
and
we
try
to
do
the
comparison
and
also
to
figure
out
which
one
is
the
best
way
to
define
an
a
young
model
and
which
one's
better
for
configuration.
H
Here's
a
brief
history
of
this
document.
They
basically
from
a
version
4.
We
began
to
compare
these
two
young
data
models
and
in
the
version
5
we
do
some
modifications
based
on
the
comments
from
down
and
working
group
chair
and
in
this
version
version
6.
We
ended
on
Thea
model
into
the
draft
two
to
show
them
directly
to
the
audience
and
other
working
with
people
to
to
see
what
it
is.
It
looks
like,
and
we
have
a
lot
of
discussions
during
every
week's
call
meeting
next
page.
Please.
H
H
Encapsulations
the
combination
between
different
kinds
of
data
plan,
encapsulation
for
different
kinds
of
data
plan
dropped
and
the
intention
of
the
general
llamado
is
to
cover
all
the
existing
data
plan,
draft
and
pay
attention
to
note
create
new
ones
and
in
the
current
version
we
could
cover
the
first
three
drops
of
listed
here,
the
tenets
IP
than
an
IP
or
MPs,
and
then
that
I'm,
Jeff
and
the
other
drops
are
not
totally
covered
in
the
investing
young
model.
But
we
will
try
to
try
to
cover
them
in
the
following
versions.
H
I
will
take
an
example
to
to
to
let
you
see
the
figures
more
clearly.
For
example,
you
know
the
first
flow.
If
the
application
is
encapsulated
in
IP,
and
you
know
service
of
layer,
it
could
be
in
capital
encapsulated
with
the
unchaste
label
internet.
We
call
it
as
label
and
also
in
the
forwarding
sub
layer.
We
could
in
capturing
capital
this
packet
with
another
F
label,
and
so
this
is
the
IP
over
mg
a
space
and
with
other
combinations
we
could
cover
other
different
kinds
of
discipline
solutions
this.
H
J
So
if
this,
this
diagram
kind
of
came
about
a
little
bit
later
than
we
probably
should
have
in
the
sense
that
we
we
started
to
track
the
different
combinations
and
then
we
said
for
this
version,
we're
actually,
like
you
mentioned,
sticking
to
a
fairly
a
fairly
strict,
simple
case
of
IP
over
MPLS
service,
sub-layer
and
forwarding
sub-layer,
because
it
it
quickly
becomes
complicated.
So
that's
why
we
focused
on
the
the
simple
case
for
now
and
then,
but
you
know,
the
intention
is
to
cover
all
cases
but
I
think,
but
by
focusing
on
that
mainline
case.
H
Next
page,
please,
yes,
here
is
the
review
of
what
we
have
discussed
the
during
the
other
way
call
meeting.
First,
we
try
to
define
the
architecture
of
the
general
model,
but
there
are
a
lot
of
ways
to
envision
the
model,
and
we
agree
that
the
structural
model
has
benefits
and
also
we
try
to
figure
out
the
building
blocks
of
them
and
Yamoto,
and
we
also
put
some
fingers
again.
The
main
list
with
we
spend
time
rebuilding
reviewing
the
basic
building
blocks
related
to
the
model.
H
Most
of
the
building
blocks
have
been
allowed
still,
some
of
them.
Maybe
we
have
different
opinions,
and
this
discussion
will
continue
and
also
we
want
to
try
to
divide,
try
to
avoid
some
duplication
information
showing
in
different
locations
in
the
young
model,
which
will
cause
confusion
for
the
readers,
especially.
H
H
H
For
example,
different
groups
of
parameters
combine
flexible,
a
based
on
the
requirement
or
use
the
same
structure
for
all
the
cases,
but
by
configuring,
the
corresponding
group
and
in
the
following
slides.
We
will
add
these
two
others
to
introduce
his
young
models.
We
introduced
the
structure
of
the
young
model
and
also
give
an
example
of
how
to
how
to
configure
the
den
Matt
slow
with
these
two
young
models.
A
Thank
you
I.
Maybe
I
misread
it
or
misunderstood
the
discussion
on
the
weekly
meeting.
I
thought.
One
of
the
other
differences
is
that
in
one
model
the
same
information
has
to
be
configured
in
multiple
places
and
in
the
other
model
you
basically
configure
pointers
to
that.
Other
information
did
I
misunderstand
that.
K
Configuration
young
motor
help
us
three
part
of
container
one
for
the
head
flow.
This
is
a
flow
container.
There
have
a
flow
name
and
segment
and
our
segment
in
segments
similar
of
this
F
low
key
value
identify
which
F
flow
is
mapping.
This
app
flow
and
our
segment
is
similar
to
result
of
this
airflow,
so
ingress
know
the
habit
chose
in
segments
as
MPs
F,
IPF
flow
and
our
segments
have
choose
lady,
the
service
sub
layer.
Reference
point:
you.
D
K
K
K
K
K
K
K
As
shown
in
this
configuration
and
protection
configuration
have
sequence
number
long
as
a
and
B
need
to
any
a
tweet
sequence.
Number
and
sub
sub
layer
in
segment
has
a
related
at
flow.
The
first
point
f1
and
our
segment
has
a
encapsulated
as
labor
involved
and
next
to
lay
a
info
answer.
After
SL
1
layer,
reference
point
and
folding
sub
layer
configuration
has
a
name
of
f1
and
their
traffic
spec
configuration.
K
K
G
K
Their
incoming
flavor
is
configured
at
in
segment
in
segment
to
have
a
label
42
and
our
segment
configurate
SS.
Everyone
indicated
sporting
in
sub
layer
pop
and
related
with
it.
Ss
a1
services
top
layer,
visible
layer,
SSA
one
has
a
protection.
Configuration
protection
type,
has
a
relay
lip
location
and.
K
K
K
K
K
K
Configuration
egress
egress
know
the
first
couple:
they
pop
the
Ethel,
oh
so
instead
I
meant
to
have
a
47
incoming
ever
labor
configuration
and
our
second
one
to
have
a
related
service
level,
a
reference
point
SS
air,
one
and
services
sub
layer,
SS
air
one
as
a
as
sellable
value.
Seven,
seven,
seven,
seven
at
the
in
segment
and
they're
our
segment
as
a
related
at
flow
reference
at
one
and
their
operation
type
is
service
termination
and
a
flow
configuration
in
segment
is
a
flow,
adding
identification
value
and
our
segment
configuration
has
an
outgoing
interface
eth1.
E
K
J
Okay,
so
a
little
bit
of
background
on
the
on
this
on
the
second
model.
Here,
what
was
happening
was
we
were
writing
the
full
model
draft
and
we
were
having
difficulty
mapping
what
was
in
the
flow
model
map
to
the
yang.
So
that
was
the
origin
of
why
we
started
within
another
model
and
it
was
basically
to
to
to
model
more
closely
following
the
flow
model.
Now
over
time.
The
the
actual
two
models
have
become
a
lot
closer
together.
J
So
this
was
the
summary
that
allows
it
actually
put
together
for
the
the
app
so
the
the
flow
model
and
it
broke
apart.
The
app
flow,
the
debt
net
flow
and
the
service,
and
these
components
were
the
things
that
we
were
trying
to
work
into
this
model,
make
sure
that
they
were
they
were
captured,
so
the
model
that
I
started
with
use
this
structure
and
use
these
attributes
in
the
model
next
slide.
J
The
application
components
are
together
both
directions,
so
you've
got
an
an
ingress
and
in
egress
in
the
model,
and
then
the
service
components
are
organized
together
as
a
complete
unit.
They
could
do
ingress
and
egress.
You
can
imagine
them
group
together,
like
they
are
in
the
application,
but
because
MPLS
and
IP
are
basically
unidirectional.
J
I've
shown
them
as
configured
as
separate
objects
where
you're
using
the
outbound
piece
of
the
service
come
the
service
configuration
in
one
direction
and
you're
using
the
inbound
in
the
other.
So
there's
a
in
the
models.
The
one
difference
you'll
see
is
that
there's
more
of
a
directional
influence
in
this
model,
where
just
that
the
directions
are
separate,
it
could
be
together
that
in
the
same
component,
if
you
wanted,
but
they
don't
have
to
be
because
the
flexibility
and
the
architecture
allows
both-
you
can
go
onto
the
next
slide.
J
So
when
you
look
at
this
level-
and
this
is
a
summarized
level
of
the
applications
tree-
you
see
very
similar
to
the
the
the
previous
diagram
that
young-cheol
presented.
The
one
difference
is
that,
like
I,
said
it's
kind
of
directional
in
the
sense
that
the
linkage
to
the
service
component,
the
outbound
and
the
in
bond
is
at
the
top
layer
and
the
ingress
functions
and
the
egress
functions
are
are
separated
from
that.
J
So,
if
you
look,
if
you
go
back
and
you
look,
you
know
I,
don't
I,
don't
suggest
we
do
it
here,
but
you
can
go
back
and
look
or
you
can
look
in
the
draft
at
the
difference.
That's
one
of
the
differences
in
the
model.
So
when
you're
configuring
you'll
see
that
we
go
down
one
branch
in
in
one
side
and
then
you
go
down
the
other
branch
and
the
other
side
and
go
on
to
the
next
one.
J
Similarly,
for
the
service
sub
layer,
there's
there's
an
outbound
side
than
in
inbound
side
and
if
you're,
using
the
interactional
model,
you'll
only
be
going
down
one
branch
of
the
tree,
if
you
happen
to
have
them
both
together
in
the
same
model,
you
could
have
both
of
them
configured
together,
go
to
the
next
slide
and
for
the
reading
sub-layer
in
the
same
same
organization.
So
for
the
reference
pointers,
I
started
out,
trying
to
make
sure
that
you
only
had
to
configure
the
reference
pointers
in
one
place.
J
It
ended
up
being
what
I
went
when
I
went
and
I
did
the
configuration
model
with
yang
lint,
the
most
obvious
place
to
do
that
was
in
the
service
sub
layers.
So
you
actually
configure
the
reference
pointers
that
you
you
will
be
using
for
the
the
various
pieces
once
in
the
service
of
model
and
the
ones
in
the
in
the
application
and
the
forwarding
layer
to
the
service
can
actually
be
inferred
by
the
backend
processes.
From
that
one
link,
so
you
don't
have
to
manage
both
of
the
pointers
and
get
them
right.
J
You
should
be
able
to
configure
the
pointers
for
the
service
references
in
one
place
go
on
to
the
next,
so
this
is
the
the
example
of
the
configuration
in
this
one
and
E.
So
you
will
see
the
the
difference
here
is
that
for
the
for
the
application
side,
there's
an
application
and
there's
only
an
application
ingress.
There
is
a
it's
not
showing
as
the
service
reference
is
not
showing
in
the
application
configuration
because
that's
a
read-only
object
and
the
configuration
that
I'm
using
and
yang
lint
is
showing
a
config
model,
not
an
operational
model.
J
Service
sub
later
reference
pointer
at
the
application
and
then
in
the
services.
You
can
see
the
application
reference
and
you
can
see
the
forwarding
sub-layer
reference
and
again
it's
it's
only
in
one
direction
in
the
in
the
services
layer
here
and
then
the
forwarding
sub
layer
again
you've
got
the
the
reference,
because
it's
it's
configured
in
the
services
sub-layer,
you
don't
see
it
in
the
forwarding
model,
because
this
is
a
config
model.
J
You
would
see
it
in
the
operational
model,
so
very
similar
attributes,
we
kind
of
aligned
our
examples
to
similar
pieces,
so
you
could
compare
them
more
easily
and
this
is
just
showing
down
at
the
bottom.
This
is
the
basically
an
application,
an
edge
node
configuration
showing
all
of
the
three
components
go
on
to
the
next
one.
J
So
in
the
in
the
reverse
direction,
when
you're
coming
back
in
from
the
forwarding
sub-layer,
you
have
a
very
similar
structure,
but
now
we're
going
an
input
and
the
forwarding
sub-layer,
and
that
goes
into
the
service
with
the
MPLS.
You
just
need
to
identify
it
by
the
service
of
label,
and
it
knows
the
because
of
the
the
application
that
is
tied
to
that
label.
It
can.
It
can
refer
to
that
application,
and
then
you
have
the
application
piece
and
then
the
application
configuration
for
that.
So
that's,
basically,
where
this
model
stands.
J
J
So
at
this
point,
we
we
have
to
figure
out
the
the
the
for
the
the
model,
what
we're
doing
and
then
get
some
more
input
from
the
working
group
if
they
feel
you
know
anything
in
these,
in
these
models
in
particular
should
be
kept,
and
we
should
be
discussing
here
what
the
next
steps
are
hoping
and
floor
up.
We've
got
a
bit
of
time
left
to.
J
A
I
have
to
say
that
I
think
from
you
know:
I
I've
been
attending
the
meetings
and
also
sort
of
trying
to
track
the
general
situation,
but
I
think
it's
really
hard
to
see
what
the
the
core
differences
are
and
what
the
core
question
that's
being
asked
of
the
working
group.
I,
don't
know
if
it
makes
sense
to
go
to
the
back
to
that
similarities
and
differences
slide.
You
know.
Presumably
it's
in
these
differences
that
the
questions
exist
right
at
which
author
I'm
addressing
this
to
obviously
I'm
addressing
it
to
any
author.
A
It
doesn't
make
sense
to
talk
from
here
and
say
you
know
what
and
for
something
one
of
the
authors.
To
specifically
say
what
question
are
you
asking
the
working
group
and,
if
you're
just
saying,
you're
doing
status
of
where
you're
working
through
and
that
you're
gonna
continue
working
through
these
in
the
weekly
meetings?
That's
fine!
You
know!
That's
that's!
Actually
a
fine
statement
also
so.
J
If
you
look
at
the
what
was
presented
today,
the
only
difference
that
I
see
is
that
not
the
only
difference,
but
the
major
difference
I
would
see
between
the
two
models
is
that
in
the
original
model
there's
this
concept
of
an
insect
in
an
out
segment
and
in
in
the
model
that
I
presented,
there's
a
there's,
a
pointer
to
the
service
sub-layer,
that's
not
in
the
out
segment,
but
it
you
know
that
is,
that
is
a
just
a
pointer
and
there's.
Basically,
the
flow
is
as
as
a
packet
or
a
frame
comes
in.
J
You
do
an
operation
on
it
and
then
you
hand
it
off
to
the
next
layer
the
when
we
originally
did
the
discussions.
There
was
a
lot
more.
There
were
sort
of
some
ingress
processing
and
then
some
egress
processing,
but
in
the
configure
configuration
models
that
I
see
today
there
was
not
much
on
the
egress
processing
anymore.
H
A
So
I
mean
from
from
my
standpoint,
I'm
hearing
that
this
is
just
an
update
and
to
let
people
know
that
the
work
is
continuing
in
these
weekly
meetings.
The
meetings
are
announced
and
open
to
everyone.
So
you
know
III
appreciate
the
the
update
and
also
the
work
to
work
towards.
You
know,
moving
things
that
are
maybe
differences
into
you
know,
figure
out
the
similarities
and
figuring
out
how
to
bring
these
together.
A
If
you
do
hit
a
point
where
you
want
input,
you
know
specific
input
or
you
know,
hit
a
roadblock,
certainly
feel
free
to
bring
it
to
the
list.
I
know
you're
discussing
this
on
the
list
of
its
free.
Also,
we
can
discuss
it
at
the
at
108,
which
isn't
too
far
away.
So
from
my
standpoint,
I
I
appreciate
the
update
and,
more
importantly,
also
as
appreciate
the
hard
work
to
bring
forward
an
integrated
solution.
So
thank
you.
A
B
Yeah
I
also
would
like
to
join
in
thanking
for
the
hard
work
done
by
by
all
the
contributors
like
finalizing
the
codata
plain
drafts
and
progressing
the
the
rest
of
the
data
plaintiffs
and
the
flow
information
and
so
on
and
and
there
now
the
rank
being
the
major
work
item
and
all
these
weekly
working
meetings
and
discussions
and
and
and
and
our
progress
made
and
very.
Thank
you
very
much
for
all
the
updates
and
looking
forward
to
moving
on
and
make
her
further
progress.