►
From YouTube: IETF102-CCAMP-20180717-1550
Description
CCAMP meeting session at IETF102
2018/07/17 1550
https://datatracker.ietf.org/meeting/102/proceedings/
A
A
B
B
So
please
state
your
name
before
speaking
and
you
know
speak
in
front
of
the
mic
so
for
the
meeting
minutes
so
I
think
if
anyone
can
take
some
minutes,
you
know
slow
there.
You
spent
the
web'
appreciate
and
I
also
asked
my
comment
and
they
can
help
us
so
I.
Think
I
also
are
the
cheers
we
are.
You
know
I
monitor
the
meeting
echo
and
to
say
if
there
are
some
comments
from
the
Jimbo.
B
I
PR
stuff,
so
we
know
you
delay
on
the
cheers
will
send
out
the
IP
I'm
polling
before
we
move
to
the
next
step,
for
example,
before
an
individual
job
becomes
a
working
group
document
or
working
group
document
goes
to
last
call.
We
were
you
know
us
and
that
idea
polling
and
you
it'll
acquires
order.
You
know
editors,
and
you
know
our
authors
and
computers
to
look
quite
IPR
as
soon
as
possible.
B
C
It
went
through
all
the
final
steps,
so
it's
ready
to
become
an
RFC
soon
soon
and
another
draft
which
is
being
processed
by
the
IES
G,
which
is
the
DWDM
interface
management
and
control
framework.
We
business
I,
would
say
on
older,
we
just
sent
a
liaison
to
the
activity
informing
them
about
about
this
work
and
asking
for
the
review
before
the
very
last
steps
in
the
in
the
ATF
process.
C
C
There
are
also
some
working
group
draft
so
that
they
will
not
be
discussed
at
today.
First
one
is
that
the
other
module.
Actually,
there
has
been
quite
a
good
discussion
about
this
draft
on
on
the
mailing
list.
It
progressed
quite
well.
We
had
significant
improvements
since
the
last
the
last
meeting.
C
We,
if
Accord
to
remember
we,
prepare
the
a
liaison
also
on
this
also
on
this
document,
but
I'm
not
sure
it
was
sent
out.
We
need
we
needed
to
double
checked
in,
and
then
we
have
a
recently
adopted
draft,
which
is
the
Flex
agreed,
the
media
channel,
the
young
model
and
the
tunnel
model
on
flex
agreed
which,
which
is,
let
me
say,
part
of
the
of
the
previous
one
and
the
microwave
young
model
these
the
past.
C
The
last
call
recently
it
has
been
reviewed
by
the
young
doctors
and
it's
now
ready
for
the
ITF
last
call
rsvp-te
bandwidth
availability.
This
document,
unfortunately,
has
been
there
for
for
a
while
lab,
we
had
the
OSPF
te
bandwidth
availability,
which
was
put
on
all
the
mutant
due
to
a
work
that
we
did
that
be
done
in
T's.
Now,
both
documents
are
are
concluded.
C
So
this
is
the
next
document
that
we
will
last
call
other
drugs
that
have
not
been
changed
since
the
last
meeting,
the
tunnel
model
for
4w
song
and
the
date
apology
for
division,
as
well
as
the
info
modeler
for
impairment.
What
wson
reasons?
As
I
said,
we
just
sent
out
a
a
liaison
to
the
study
group
15
regarding
the
DWDM
interface
management
and
control
framework.
C
This
was
submitted
in
in
May
actually,
but
it
wasn't,
it
was
not
delivered
that
so
the
ITU
is
expected
that
work
on
this
to
review
the
liaison
next
time
they
will
be
meeting.
So
this
is
it
we
can
start
anyone
willing
to
make
comments
on
the
agenda.
Add
topics
if
none
we
can
start
with
the
first
presentation
from
hallo.
D
Okay,
thank
you.
Mr.
Luthi
I'm
co-chairing
with,
together
with
Daniel
the
design
team
or
transport
Envy
I
am
status,
update
since
the
last
IDF
meeting.
Okay,
quick
recap
about
our
goals
and
deliverables.
So
the
intention
is
to
analyze
out
the
ITF.
Ahmadis
are
applicable
to
transport
networks
at
the
NVRA
transport
networks,
and
we
work
on
many
lists
and
conference
call
and
we
have
a
key
table
while
we
track
the
code
and
the
open
issues
them.
D
So
our
delivery
deliverable
up
to
now
is
the
draft
which
is
doing
an
applicability
statement
for
transport
MBI,
so
analyze
how
the
IDF
Yamada's
can
be
used
to
control
a
multi
domain.
Otr
networker
and
we
have
in
this
Rob,
will
provide
a
description
of
what
is
the
multi
dome
scenario.
A
reference
scenario
for
a
multi
domain
optical
network,
which
is
in
the
description
of
what
needs
to
be
done,
is
in
the
panel
from
the
young
model.
D
And
then
we
go
into
the
details
to
see
which
young
model
developed
by
ATF
are
you
and
how
they
are
used
to
meet
to
control
the
require
that
that
scenario
and
we
provided
tailor
code
examples
of
the
J's
on
that
with
the
exchange
of
the
different
MPI
so
and
on
the
different
end
before
the
focus
on
our
draft
is
DMP
is
between
the
MDS
CM,
multiple
pcs
were
we
ever
to
describe.
We
describe
the
pathologist
action
or
al
DMV
aps-c,
sorry,
the
topology.
D
It
is
controlled
to
the
MDS,
see
how
the
service
is
configure
the
foreign
on
to
and
multi-domain
scenario,
and
how
protection
restoration
and
and
also
said
we
have
added,
also
service
modification.
What
happens
when
the
service
is
modified
from
protected
to
unprotected,
for
example,
the
reference
network
is
outlined
here,
so
we
have
a
different
customer
key
mentor
outside
of
our
control.
The
assess
links
are
supposed
to
be
10,
gigabit
assess
linker,
and
we
have.
The
network
is
partitioned
into
three
different
network
mesa
and
for
each
net
Romania
we
have
a
PNC.
D
So
the
scope
of
the
draft
at
this
moment
are
the
tree
and
Taizo
between
the
three
PMC
and
the
mtsc,
and
the
current
version
is
analyzing
in
details,
new
version
of
the
rotary
arising
in
details
down
to
the
detail
to
the
average
JSON
code.
What
do
we
are?
What
is
the
audio
topology
and
the
audio
to
service
and
the
EPL
overall,
due
to
service
configured
over
the
pnc
one?
We
need
to
complete
the
example.
What
are
the
models
that
we
are
analyzing?
D
The
Tito
polish
and
tunnel
model
which
are
under
developed
almost
closed
by
teesta,
did
OTN
topology
erosion
tunnel
and
developing
here
in
C
camp,
and
we
have
also.
We
are
also
using
an
individual
draft
that
has
been
submitted
to
see
camper
for
the
configuration
of
the
eternal
client,
so
how
you
set
up
to
set
up
a
DPL.
D
How
do
you
configure,
which
part
has
to
be
mapped
over
the
audio
tunnel,
and
we
have
in
it
all
day
what
we
are
doing
on
JSON
the
JSON
is
validated,
so
we
have
a
you
use
a
Sun
to
linger
to
contract
that
the
JSON
code
that
we
developed
is
is
valid.
Json
and
is
compliant
with
the
young
model
that
has
been
developed,
so
the
JSON
code
is
correct.
It's
not.
There
are
no
Maxo
and
we
have
a
some
tooling
here.
D
Whether
this
validation
code
validation
is
allocable
to
a
broader
scope
than
just
transporting
VI
JSON
code.
So
whether
or
not
to
take
the
appendix
piece
from
our
draft
I'm
moving
to
a
net
mode,
the
working
group
draft
to
make
it
available
to
the
broader
community.
This
then
just
the
design
team,
so
everybody
who
writes
a
JSON
code
can
check
that
is,
code
is
in
line
and
compliant
with
a
young
mother,
open
issue,
sir,
so
where
we
are
at
this
momentum,
we
have
to
first
of
all
try
to
prioritize
the
botargo
to
be
the
next
examples.
D
We
still
have
a
lot
of
work
to
do
in
the
details,
so
we
have
to
describe
EVP
le
multi-point
internet
services
as
supported
by
Oceania.
We
have
a
some
description
to
do.
How
do
we
manage
the
assessed
multi-access
function,
access
links
or
some
1010
bit
assessment,
which
can
be
configured
to
be
aught
you
to
10,
Gigabit,
Ethernet
or
STM
64?
So
how
do
we
manage
that?
How
do
we
control
protection
restoration
and
how
do
we
modify
the
service
characteristics?
D
We
need
to
give
a
priority
list
of
all
these
items,
and
one
other
big
issue
we
are
discussing
is:
how
do
we
identify
the
topology
elements?
So
there
are
many
data
files.
The
final
two
are
s
and
T
topology
models,
and
we
have
some
different
ideas
and
we
are
still
discussing
them
trying
to
understand
how
to
populate
the
decision
to
fire
which
being
compliant
with
the
requirements
that
we
have
in
this
draft
and
doing
is
discussion.
D
We
got
some
questions
from
people
about
whether
we
should
not
propose
a
sort
of
a
best
practice
with
in
VI,
so
the
standard
model
is
very
flexible.
People
can
can
write
down,
can
put
any
identifier
schema
and
but
the
question
is,
can
we
recommend
that
on
the
mbira
transport
network,
that
this
is
our
best
passes
recommendation
and
the
question
is
can
with
what
about
doing
data?
And
the
second
question
is
whether
this
is
a
best
practice.
We
should
know
document
and
there
were
some.
D
So
when
we
can
go
home
bed,
then
the
next
steps
is
to
work.
So
we
address
all
the
operation.
Technical
issue:
we
we
still
have
a
pending
issue
from
the
last
time.
We
want
to
align
the
text
with
the
eighty
tutorial
developed
by
thesis
so
checking.
Where
is
application
over
recent
text
in
our
document
that
should
go
there
and
make
sure
that
we
avoid
the
text
overlapping
with
you
to
document,
sir.
D
We
need
to
complete
the
examples
for
the
existing
service,
like
what
you
and,
if
you
had
another
client
to
cover,
also
the
other
domains,
not
only
domain
number
one,
and
we
have
a
based
on
priority
at
the
new
examples,
and
we
have
two.
As
we
said,
we
have
to
discuss
both
priority
order
and
we
are
planning
to
have
a
face-to-face
meeting.
We
didn't
know
the
time
this
morning,
Daniel
announced
today,
we
have
found
the
best
lot
for
the
participants
is
going
to
be
tomorrow
between
12:30
to
1:30
and
we
are
meeting
by
the
ITF
registration.
D
E
D
Environment,
actually,
what
we
did
in
the
design
in
the
document,
we
were
not
saying
that
every
every
network
domain
is
a
single
vendor,
but
it's
an
underlying
assumption.
Basically,
the
idea
is
that
this
set
of
network
elements
are
controlled
by
a
single
controller,
which
is
PSE
one
this
one
by
second
PSE
three
and
this
one
by
PNC,
two.
D
E
D
D
E
F
E
Should
be
I
think
it
should
be
clear
what
those
boundaries
your
your
means,
let's
say
but
I
when
I'm
looking
at,
is
I
kind
of
understood
that
this
should
be
kind
of
controller
domains
yeah,
but
the
way
it
is
often
described
is
kind
of
a
ho
TN
or
technology
domain.
If
you
look
at
it,
it
appears
to
be
a
technology
domain
which
is
not
necessarily
the
case,
so
I
think
we
should.
We
should
grasp
a
little
bit
better
what
what
the
main
already
means.
D
A
D
E
E
Yes,
so
if,
if
you
would
think,
for
example,
let's
assume
that
you
get
a
little
bit
away
from
router
or
not
router,
but
let's
assume
your
stay
on
layer
one
and
you
had
a
sonic
cross
connect
with
no
TN
in
the
face
facing
into
your
WDM
right
here,
yeah
mm-hmm.
So
then
there
is
certainly
a
boundary
between
sonnet
and
OTN
mm-hmm
yeah,
plus
there
is
a
boundary
within
do
TN
yeah.
I
E
D
I
think
at
one
point
they
drafts,
assuming
that
all
this,
not
our
audio,
switching
capable
nodes,
so
we
care
about,
and
then
we
maybe
need
to
be
more
clear.
We
care
about
audio
layer
at
this
moment
in
time
in
the
optical
t
statement,
and
the
other
assumption
is
that
this
link
is
configured
up
to
the
o2
four
level.
So
all
the
transponder,
all
those
issues
are
solved
by
means
which
are
not
controlled
by
the
API.
D
So
what
you
have
you
have
this
out
you
for
Setar
from
here
to
here,
which
provides
to
the
mdac
a
capability
to
set
up
all
you
over
this
audio
linker
and
then
what
we
have
is
also
here
is
the
boundary
where,
as
you
said
here,
if
it
is,
if
it
is
allowed
you
to
that's
easy,
so
you
have
a
Nadia
coming
here
and
then
you
have
to
carry
do
do
through
all
the
network
and
the
living.
This
was
a
simple
case.
It's
the
most
complex
case,
for
example.
D
That,
and
that's
where
we
have
an
individual
draft
added
is
that
when
a
I
have
a
the
attention
apetito
are
coming
here,
then
you
have
to
say
that
they
audio
tunnel
that
the
starts
from
here
and
Dasia.
It's
actually
carry
traffic
coming
from
this
eatin
a
porter
and
how
this
is
a
traffic.
Is
it
so?
It's
internet
is
part
of
a
specification
or
its
villain
based
classification
and
that's
where
we
added
a
needed
for
the
other
drafter,
which
is
not
the
Odeon
trusted.
D
E
J
E
A
E
D
Add
roughly
said:
one
option
is
that
these
guys
is
do
the
adaptation
between
packets
about
you.
Then
you
deliver
a
low
do
so,
and
this
case
we
don't
care
because
we
don't
see
the
adaptation.
What
we
see
is
in
audio
coming
in
and
we
switch
the
audio.
The
second
case
is
this:
guy
is
sending
packets
and
then
here
we
need
to
do
other
tation
between
packets
and
not
you.
You
only
don't
care,
because
in.
E
E
D
A
C
E
Of
nodes:
well,
you
know
if
you're
running
in,
let's
say
router
network,
you
have
a
several
C
lies.
You
can
access
your
note.
It's
not
one
client,
the
client
right
the
controller.
It
can
be
more
than
one
client
accessing
the
note.
So
what
does
it
mean
to
be
one
controller?
To
give
you
another
example,
a
famous
let's
say
new
thing
is
telemetry
data
right,
so
it's
collected
by
some
controller.
E
So
it's
it's
kind
of
it's
very
hard
to
define
term
domain.
That's
why
a
little
bit
insisting
getting
it
right,
because
it's
simple
to
say:
oh
well!
This
is
kind
of
something
fluffy
based
on
technology
adaptation,
because
it
gives
you
a
kind
of
a
feeling
of
having
it
well
defined.
But
if
you
think
about
an
adaptation
being
the
boundary,
then
the
boundary
of
the
network
domain
always
goes
for
a
node.
If
it
is
not
the
adaptation,
if
it
is
a
link
right.
E
Not
assuming
it
so,
but
I
also
want
to
say
that
the
assumption
that
one
domain
is
controlled
by
exactly
one
controller
is
equally
flawed,
so
there
are
many
controllers,
often
accessing
that
or
not
so
some
I've
only
read
it
says
some
of
readwrite
access.
You
have
the
old
element,
management
system
kind
of
thing.
If
you
could
screw
up
a
lot
of
things,
so
it's
really
hard
to
define
what
the
heck
is
this
to
make
mm-hmm.
B
So
I
have
one
comment
about
the
term
notion
and
definition
of
the
terminology
of
the
men,
because
you
know
actually
different.
That's
do
they
have
different
definition,
even
for
the
same
terminology,
so
here
we
are,
we
should
use
the
ITF
language
forgotten
bad,
at
least
that
you
know
in
the
ITF
there
are
some
jobs.
They
also,
you
know,
have
clear
definition
of
the
domain,
so
we
can
just
lepprince
to
those
jobs.
The
cutest
in
you
know
definition
of
the
domain.
K
D
D
L
Well,
hello,
everyone!
This
is
how
men,
speaking
from
Huawei
and
I'm,
presenting
the
two
graphs
after
a
young
model
for
OTN,
topology
and
tano
respectively,
and
the
first
drafter
is
about
the
OTN
topology,
and
this
is
0-3
abortion
and
we
update
a
few
terms,
including
bose
attacks
and
the
young
models
for
the
tax
change.
L
So
for
the
attributes,
we
include
some
very
specific
terms
like
tributary
slot,
granularity
distance
index
and
client-facing
stuff.
This
is
just
directly
augmented
to
the
T
topology
lives,
but
and
the
other
augment
to
the
bandwidth
and
label.
We
have
actually
the
same
group
of
parameters
but
augmented
to
multiple
places,
the
ins
already
new
young
tree
and
for
many
ways
we
want
to
include
the
audio
type
and
the
corresponding
numbers
for
the
label
and
especially
for
the
label
star
and
label
and
holders.
L
L
A
L
Okay,
thank
you
so
for
yeah,
for
the
I
abilities
is
fine,
but
here
we
cut
and
paste
what
we
have
done
for
the
tip
and
with
empty
label
respectively.
Actually,
as
there
are
many
interests
in
the
base
mode
also,
we
need
to
augment
everywhere
the
same
parameter
set
and
do
it
multiple
times.
So
we
received
some
comments
on
mailing
list
talking
about
this
issue,
but
I
think
this
a
problem
has
been
discussed
when
the
ISP
was
reviewing
the
the
base
model
and
also
discussed
with
net
motive
working
groups.
L
So
our
augmentation
is
consistent
with
the
outcome
of
this
kind
of
discussion
and
we
also
follow
the
guidelines
so
that
it's
provided
in
the
tea
topology
craft.
There
is
a
special
section
telling
you
how
to
augment
to
this
model
by
introducing
those
kind
of
technology,
specific
issues,
and
now
it
is
done
like
this.
L
L
N
N
So
many
questions
related
to
it.
The
sender
request
the
young
doctors
mailing
lists
that
the
chairs
can
do
that.
You
can
even
request
an
early
review
even
before
the
last
call,
and
I
would
suggest
that
if
you
have
concerns
do
that
soon,
yeah.
E
So
just
one
question
for
clarification:
you
mentioned
already
that
this
is
about
ODU,
but
where
do
you
plan
to
put
the
otu
so
two
motive
of
the
model?
So
if
it
is
WDM,
probably
it
will
not
show
up
in
a
WDM
side
and
if
it
is
not
ODU,
it
will
not
show
up
here.
Yeah
there
will
be
a
third
one
or
how
do
you
find
it
was
ot?
You
know.
Q
L
L
So
the
next
drafter
is
about
the
OT
in
tunnel.
This
is
going
together
with
audio
topology
and
yeah.
We,
we
gave
a
talk.
We
updated
twice
during
the
from
the
previous
meeting
and
including
both
that
has
two
changes
and
the
young
model
changes.
So
this
one
has
compared
with
the
one.
This
one
has
louder
changes,
because
we
we
have
the
OT
in
Honolulu
young.
We
have
bought
in
types.
We
have
a
RPC,
especially
specifically
for
the
tunnel
quarry,
so
we
provided
the
corresponding
description,
updated.
L
L
L
Great,
it
works
so
already
also
the
same
some
repeating
for
the
parameter
list
due
to
multiple
interest
of
the
T
bandwidth
and
T
label,
and
now
we
just
notice
that
that
eternal
model
is
still
and
they're
working
in
the
his
working
group
and
we
we've
now.
The
current
version
is
aligned,
always
with
the
latest
of
the
tea
panel
and
the
we
wish.
L
The
augmentation
principle
can
be
the
same
as
topology
augmentation,
so
I
wish.
We
won't
have
a
big
change
on
the
t-handle
model
and
also
this
was
this.
Augmentation
is
currently
good
and
the
further
Houghton
types
we
didn't
change
the
code
itself,
but
we
did
figure
out
some
issue
that
may
be
misleading.
For
example,
the
term
here
tributary
protocol
type.
We
may
think
we
rather
use
the
audio
tight
to
indicate
the
meaning,
because
it's
just
define
what
is
possible
types
of
the
audio
signals,
and
some
of
the
prefix
need
to
also
be
addressed.
L
The
currently
we
have
protocol
base
and
find
signal
base
by
actually
by
discussing
with
the
audio
orders
we
sink.
This
may
not
be
necessary
and
we
need
to
come
by
a
little
bit
to
simplify
a
little
bit
and
remove
those
kind
of
prefix
so
and
the
other
issue
is.
We
want
to
align
this
kind
of
types
of
with
other
models,
especially
for
layer,
1
CSM,
so
because
we
are
carrying
similar
signal
types,
but
we
do
not
need
to
define
separate
identities
for
the
same
term
like
it's
also
like,
for
example,
the
STM
one.
L
We
are
currently
using
this
one
in
the
model
and
we're
going
to
change
it
with
STM
one
to
be
aligned
with
so
near
what
CSM
and
for
the
next
step,
I
think
yeah
we
need
to.
We
may
need
further
update
according
to
the
negative
change
out
the
teeth
on
the
model.
I
believe
there
won't
be
on.
There
won't
be
a
big
change
and
also
we
asked
you
need
to
further
align
with
the
RPC
in
past
commutation
model
and
the
way
I'm
working
on
that
and
now
the
model
is
also
a
window.
Bourget
happen.
L
N
Maya,
Shaitan
and
Danny,
have
you
looked
at
the
yang
guy
author's
guidelines
for
how
to
write
the
model
sixty
eighty
seven
days
in
particular
for
RFC
1687
this
for
what
so
it
has
guidelines
on
how
a
yang
model
needs
to
be
written,
so
it
has
a
security
consideration.
Section
I've
not
looked
at
your
document,
it's
specific,
but
yeah.
I
would
highly
suggest
that
you
go
through
those
guidelines.
N
L
J
N
C
Finger
before
us
ending
the
draft
to
the
young
daughters
for
review
is
to
fix
what
is
he
still
there
because
I
mean
if
we
change
something
after
the
young
daughters
review,
we
might
need
to
go
for
another
round
and
the
eternal
model
is
not
yet
is
not
yet
passed.
The
working
group,
the
last
goalie
faculty
member,
so
it
might,
we
might
have
changes
also
there
so
I
think.
C
J
Yes,
I
think
our
district
was
adopted
in
the
last
meeting
yeah
and
then
I
went
to
any
f22
meeting
and
to
present
this
one
because
see,
champ
has
a
liaison
with
any
F
on
layer,
1,
CSM,
work
and
actually
those
were
very
well
received.
They
like
this
model
because
they
don't
have
a
data
model
for
layer,
1
service
attribute
and
they
I
think
you
know
long
mu,
F,
comment
and
also
some
patches
comment:
the
raw
suggestion
to
separator
out
service
types
from
the
main
module.
J
J
It'll,
be
you
know,
something
else,
not
any
F,
but
they
are
1
or
whatever,
and
then
some
service
type
so
that
we
can
refer
both
of
them
if
any
mod
module
need
those
references
and
we
had
a
pretty
heavy
traffic
from
ton
patch
for
last
one
months
or
so,
maybe
last
few
weeks
or
so
so
I,
don't
know
what
to
call
details
on
that,
but
the
indentation
issue
and
separation
of
service
style,
references,
timing
of
all,
etc.
So
and
also
he
won
JSON
an
example.
J
So
the
readers
can
read
understand
easily,
so
we
actually
accommodate
all
of
them.
So
this
is
a
current
young
tree,
so
we
have
access.
You
need
list,
multiple
of
them
and
you
nee
idea
and
protocol
encoding,
an
optical
interface
which
is
actually
coming
from
muf
service,
not
tight,
and
then
we
define
services,
instances
and
and
I
mean
if
guy
said,
you
know
their
service
identified,
it's
a
five
tuple
I,
don't
know
why
they
have
five,
but
they
wanted
to
add
all
those
five
layer.
J
J
One
pending
issue
is
a
readability
of
l1.
I.
Think
on
touch
in
particular
set
l1
is
hard
to
read
what
is
L.
What
is
one
so
he
so
there's
something
else,
but
I
said
I'm
gonna
ask
working
group
if
this
is
worse
to
change,
which
I
prefer
not
to
change,
because
it
may
not
serve
other
stuff.
I,
don't
know,
but.
J
So
if
anybody
prefer
changing
name
just
because
it's
hard
to
read
l1,
but
this
one
has
been
convention
for
l1,
l2
l3,
so
I
just
want
to
follow
convention
here,
I,
don't
think
it's
a
big
deal,
but
some
people
like
big
deal
out
of
it,
but
I
just
want
to
ask
working
group.
If
you
prefer
to
change
please
let
me
know
so
that
I
can,
let's
think
about
it,
but
otherwise
I'm
gonna,
stick
to
this
okay
and
default
value
for
performance
monitoring
period.
I
think
one
months
of
be
a
good
default.
N
You
like
yeah
Mahesh
chicken
and
an
incident
since
I
have
worked
on
in
both
ATF
and
meth
mm-hmm.
In
particular,
we
have
worked
on
meth
services.
Young
model,
yeah
I
would
do
to
look
at
the
yang
models
that
meth
has
published
and,
in
particular
the
service
types
they
have
already
defined
and
make
sure
that
your
model
is
aligned
with
that
model.
Sure
that's
good
point.
Could
you
send.
J
To
the
list
the
particular
NDF
reference
amir
sheriff
t1,
it's
meh,
5858;
okay,
thank
you
great
yeah,
so
and
then
performance
monitoring
period,
one
month,
sure
and.
H
J
Yeah
they
sent
and
then
c-can.
Maybe
you
can
send
bad
that
you
know
be
consistent.
At
least
you
know
it
may
not
be
end
up
saying
but
Elise
you
know
Avila,
yes
and
performance
monitoring
being
one
month
default.
I
think
this
might
be
a
good
thing,
but
we
don't
want
to
impose
anything
to
the
model,
so
we
haven't
put
that
as
a
different
value,
but
also
min
max
value
and
Jason
example
is
provided
here
just
to
to
configure
how
to
do
that.
So
this
is
just
updated
in
the
this
afternoon.
J
So
I
think
I
take
my
hash
right
yeah.
My
ice
comment
actually
I'm
going
to
nef.
Next
to
it
are
you
going
yeah
I'm
gonna,
ask
at
least
look
at
your
reference
so
that
whether
there's
any
duplication
and
we
take
it
out-
okay,
I
think
that
might
be
the
biggest
issue,
yes
right
and
so
far
and
I.
Think
because
of
thanks
to
Tom
I.
Think
document
is
now
putting
a
lot
of
stop
references,
security
and
consistency
for
the
you
know,
all
the
logistics
and
so
on.
So
hopefully,
next
one
more
revision
after
nef
meeting.
J
J
C
J
J
B
J
E
J
J
The
source
adopted
actually
last
F,
the
last
IETF
I
believe
and
the
scope
of
this
document
is
encoding
general,
including
for
employment
data
for
table
son.
They
can
support
multiple
protocol
enhancements,
so
SB
of
T
and
RS
PPT
and
she
said,
could
use
this
encoding
defined
here.
So
changes
from
previous
version
was
not
much
but
add
a
few
sentences
sentences
to
make
it
clear
the
right
reference
and
right
wording.
So
we
basically
extending
seven
five:
seven
nine
connectivity
matrix
defined
there
to
include
in
impairment
data,
likewise
a
resource
block
defined
in
seventy
five.
J
The
spin-around
but
just
accepted
but
I
think
document
needs
some
section.
That
says
how
specific
protocol
can
enhance.
Dictionary,
encoding
I
think
that's.
Actually
your
deters
question
how
to
use
this
one
in
the
specific
protocol
encoding.
So
we
are
going
to
add
that
section
later
with
just
you
but
I
have
one
generic
question
for
those
chairs
I
think
generic
encoding
was
develop,
October,
listen
to
think
that
whether
we
need
genera
encoding
or
not.
J
So
this
means
after
this
draft
we
have
to
have
the
three
separate
draft
which
is
specific
to
OS
QFT
and
then,
if
there's
our
three
key
enhancement
and
medet
is
a
few
seconds
actually
separate
issue,
because
it's
not
in
this
working
group.
What
do
you
think
is
worse
way
to
put
it
here
if
there
one
place,
but
we
specify
how
to
apply
this
generic
encoding
instead
of
having
another
to
document
which
may
take
another
year
to
progress
rather
I
suggest
pre
it
here
so
that
it's
the
one
shot.
J
C
Obviously,
the
difference
is
that
this
is
a
working
group
document,
so
all
the
fold
encoding
that
needs
to
be
doing
by
the
working
group.
On
the
other
side,
if
you
decided
to
start
a
new
work
as
individual
contribution,
it's
the
author,
so
that's
the
side
of
water
to
put
there.
This
is
the
difference
between
putting
it
here
who
start
in
you
individual
contributions
that
this
is.
J
C
J
C
R
And
hello,
everyone-
and
this
is
Damian
from
Huawei
I'm-
going
to
present
a
young
data
model
for
microwave
technology,
so
an
overview,
it's
a
younger
to
draft
a
data
model
to
describe
down
microwave
technology,
and
we
are
shown
basically
just
to
use
case
at
this
moment
for
the
top
knowledge
model.
Ways
for
the
resource
management,
for
example,
weekly,
the
reports,
microwave
clean
frequency
or
something
I
always
relate
the
wisdom,
microwave
link
so
which
could
enable
you
to
have
a
whole
network
view
and
the
second
power.
R
J
R
Thank
you.
So
that's
not
changes
in
this
derivation.
We
add
some
new
didn't
know
the
definition
Hawaii's
for
microwave,
unreserved
fun
wise.
So
this
is
for
past
computation,
they
use
case
and
then
the
second
point
is
that
we
add
a
mount
point
for
interfaced
model.
So
I
will
explain
more
about
this
point
and
regarding
the
unreserved
upon
us,
so
we
are
wondering
we
are
thinking
about
how
this
I
reserve,
the
balance
is
calculate,
so
there's
might
be
two
different
understanding.
R
The
first
way
is
that
we
use
the
nominal
vandalise
to
exclude
TDM
and
then
subscribe
Ethernet,
and
that's
the
original
noise
that,
as
I
mentioned
about
that
the
ban
was,
will
changed
from
time
to
time
so
that
another
way
to
do
this
calculation
is
to
use
the
current
bandwidth
to
do
this
calculation.
So
in
such
a
way,
this
might
cause
some
ambitious
me
understanding,
so
we're
thinking,
maybe
a
better
way,
is
to
define
the
reserve,
the
bandwidth
from
another
site
so
just
to
use.
R
We
will
use
the
microwave
reserve,
the
van
wise,
to
represent
how
the
TDM
and
last
isn't
it
funny
ways
in
reserved
on
the
microwave
ink
and
some
we're
trying
to
answer
the
questions
we
have
listed
in
the
first
slides
first
day.
It's
a
house,
the
relationship
between
the
topology
model
and
the
interface
model.
R
We
actually
do
some
search
among
the
related
offices,
actually
FCAT
199.
It
says
that's
narrowing
office
of
models
or
Lowe's
for
reusability
of
existing
Norlin
models
by
hire
letter,
low
modules,
we're
limiting
duplication
of
features
across
layers,
but
in
81
99
it
doesn't
say
how
how
to
do
so.
So
we
screw,
we
found
more
clues
from
83
45.
R
Instead,
this
is
about
the
technology,
a
network
technology
model.
So
it
says
that
the
nodes,
the
example
of
the
termination
point,
might
be
a
physical
or
logical
port
or
more
generally,
an
interface.
So
this
is
very
important.
Then,
in
net
mode
there
is
a
scheme,
amount
dropped
which
defines
a
scheme
amount,
and
this
mechanism
will
enables
you
to
have
a
set
of
young
modules
onto
among
to
point
in
the
schema
tree
in
some
young
modules.
So
you
see.
R
The
mountains
is
deviation
model
to
the
interface
node,
so
this
provides
the
flexibility
based
on
your
requirements,
but
then
another
point
we
might
change
to
this
interface
road
is
that
this
could
be
an
optional
feature.
It's
natural,
it's!
You
should
not
be
monitoring,
so
we
will
change
this
to
optional
in
this
version
and
regarding
the
Ethernet,
topology
and
the
microwave
technology.
So
we
have
some
clues
from
the
tea-table
logic
model.
R
So
in
in
this
example,
we
will
say
we
are
trying
to
answer
the
question.
Also
combined
with
the
formal
second
question
and
the
third
one
you
will
say
that
is
the
in
the
figure
we
have
the
one
overlay
topology,
that
is,
isn't
it
topology
and
the
continuity
topology
is
in
microwave
and
in
the
TD
topology
is
a
little
year.
We
will
say
that
there
will
be
under
layer
features
related.
R
The
microwave
relay
deeds
didn't
know,
definitions
in
this
one
place,
and
then
another
common
use
case
for
is
that
we
will
use
to
microwave
things.
She
supports
academic
services
with
much
wider
bandwidth
requirements
so
in
in
such
a
way
where
we
are
discussing
how
to
model
in
this
case.
So
after
the
ethernet
layer,
there
will
be
same
as
the
former
case.
The
only
difference
lays
in
the
top
of
microwave
technology.
So
we
will
have
the
microwave
kernel,
it's
it's
supported
by
two
microwave
links
and
we
will
use
the
TDP
local
mega
connectivity.
R
R
So
the
next
steps
is
that
we
were
planning
to
resolve
those
opening
issues.
For
example,
the
first
one
is
whether
we
should
continue
use
the
unrep,
unreserved
and
west
all
reserved
bandwidth
and
then
changes
among
hundred
to
an
optional
feature
and
then
editorial
improvement
example
to
explain
how
the
topology
and
interface,
especially
the
link
in
the
topology
model,
is
actually
the
link
between
the
carrier
termination
in
the
interface
model,
just
to
be
more
clear
how
these
two
models
are
ready
with
each
other,
and
we
will
also
update
the
appendix
examples.
R
So
any
comments
and
reviews
are
march.
Welcome
and
another
information
is
that
we
we
have
done
and
practiced
which
will
be
hosts
in
HCI,
CM
WT
investor
january.
So
this
mode
of
combined
wastes
other
t-tubule
knowledge
modo
and
network
turbulent
model
will
be
verified
in
the
podcast
and
then.
Finally,
we
would
like
to
ask
for
a
working
board
option
and
to
use
this
as
a
starting
point
to
define
dessert
to
broli.
S
Risk
in
hallway,
so
we
had
some
discussions
about
this
model
and-
and
basically
we
mentioned
that
say
you
can
split
into
two
independent
topologists
overlay
and
underlay
right
so
or
way
another
layer.
They
are
not
independent
apologists
and
they
are
related,
basically
in
a
way
that
tunnels
in
the
underlay
topology
support
links
in
the
overlay,
topology,
correct,
yeah,.
S
So
who
so?
The
thing
is
that,
if
underlay
topology
is
is
a
microwave,
it
means
that
the
tunnels
blocked
links
in
microwave
support
links
in
the
internet
apology,
so
the
the
fact
that
in
just
one
hope
tunnels
it
doesn't
change
anything.
Okay,
conceptually
it's
still
tunnels.
Okay,
that
support
our
one,
one
hope:
tunnels
that
support
the
ethernet
links
and
the
tt
piece
in
the
microwave
right.
They
kind
of
coincide
with
the
LT
peace
in
the
Ethernet.
R
Okay,
so
actually
we
would
the
one
of
the
formal
discussion.
We
have
the
options
which
puts
its
net
and
microwave
into
one
technology,
but
I
didn't
check
with
the
latest
Ito
biology,
because
what
I
referencing
is
it's
in
a
formal
prison
presentation
starts
out,
so
I'm
not
sure
if
it's
not
allowed
in
the
current
draft,
but
if
it
is
still
allowed
a
single,
we
will
still
prefer
in
such
a
way
because
it's
will
be
seemed
more
clear.
R
S
Not
about
first
of
all
to
topology
hasn't
been
changed
for
quite
a
while.
It's
a
it's
ready
for
publications,
it's
about
to
be
a
NRC.
Secondly,
it's
not
a
topologist
relationship.
It's
actually
several
client
relationship
when
they're
territorial
supports
are
like
a
link
in
the
upper
layer,
the
client
layer,
okay.
So,
in
order
to
carry
different
frames
over
a
microwave
connectivity,
it
means
that
you
have
a
tunnel
in
microwave
network
that
supports
link
in
the
Ethernet.
So.
R
T
R
To
the
chief
yes,
and
so
we
we
have
a
frequency
channel
separation
and
the
nominal
bang
noise
I
think
it's
an
important
thing
is
for
bandwidth
nominal
and
it's
apparent
I
understand,
there's
some
Chi
vandalizing
the
technology
that
it's
doesn't
reflect,
how
the
bandwidth
will
change
from
time
to
time.
How.
R
T
And
you
can
I
using
the
term
media
channel
because
that
has
a
connotation,
a
very
high
data
rate
right
yeah,
but
guess
what
it
also
applies
at
very
low
data
rates
for
other
RF.
It
seems
like
this
is
a
general
concept
and
I
I've
looked
at
your
draft
a
couple
times,
but
I
can't
say
I'm
an
expert
on
its.
You
know
think
it's
just
skimmed
it,
but
it
seems
like
there's
a
lot
of
good
stuff
there,
but
it's
not
microwave
specific
yeah.
So.
R
T
You
started
putting
in
signal
parameter
signal
strength
parameters,
you've
got
a
plot
that
applies
at
you
know,
any
anything,
that's
basically
doing
interesting,
RF
modulation
and
when
we're
doing
that
in
all
sorts
of
media
these
days
from
again
from
very
low
data
rates,
the
very
high
data
rates,
so
it
would
be
yeah,
it's
good
work.
I,
just
think
it
should
be
made
applicable
to
all
of
those
types
of
channels
yeah.
So.
T
T
B
U
T
U
U
T
P
I
Now
the
scenario
is
changing,
because
on
top
of
this
type
of
network
it
it
can
be
the
controller
hierarchy
like
a
CTN,
and
these
impose
the
question
mark
about
interwork
about
the
setup
protocol
that
is
managing
one
and
the
other
network,
and
the
intent
of
this
of
this
draft
is
to
make
understandable
how
this
technology
can
inter
work
each
other
to
operate.
The
network.
I
I
This
is
the
picture
that
is
described
the
topology
scenario
in
which
we
have
three
level.
There
is
the
network
neighbor
level
with
the
local
resource
discovery
with
the
basically
LMP
protocol.
We
have
a
network
level
with
topology
discovery,
with
floating
information
among
a
manganese,
with
typically
provided
by
link
state
routing
with
us,
PF
RSS,
and
then
there
is
the
the
third
one
that
is
the
possibility
of
topology,
based
on
TC
controller,
to
any
relationship
with
the
interaction
between
PC
controller
to
any.
C
I
K
I
I
Okay,
this
is
the
table
that
is
representing
the
case
of
service
provision.
We
have
different
two
points.
There
is
the
step
of
the
precision
with
pod
computation
but
establishment
and
they
updated
the
database
and
the
mode,
and
we
are
separated
that
the
different
mode
in
which
we
can
obtain
that.
So,
basically,
there
is
the
case
in
which,
traditionally,
with
gmpls
a
control
plane,
we
have
distributed
control
plane
with
math
computation
based
on
OSPF,
with
path
setup
based
on
our
sweeties
signaling,
and
the
resource
update
is
made
again
by
OSPF.
I
I
Now,
with
the
with
the
Sdn
scenarios,
with
the
net
conf
raskov
protocol
that
can
obtain
topology
and
then
provide
path,
computation
based
on
the
topology
that
is
obtained,
and
then
there
is
the
past
setup
beta.
That
is
the
beauty
singing
so
again
with
Allison
PT
and
the
dairy
Susa
plate.
Kanda
can
be,
or
basal
OSPF
or
again
with
precept,
LS
or
net
code,
and
that
the
third
case
it
is
the
centralized
case
in
which,
okay,
yes,
we
adopted
the
term
centralized
signaling
with
central
spot
computation.
Maybe
centralizing
is
not
correct.
I
I
I
Well,
so
now
we
are
open
to
the
suggestion
about
improve
the
document.
What
is
the
dictionary
that
has
been
proved
already
in
the
document?
What
can
be
the
issue,
and
so
that
is
what,
while
a
spending
effort
to
underline
there
in
the
document,
so
we
open
to
hear
about
the
working
group,
our
suggestion
to
put
the
document.
T
T
T
I
can't
speak
for
my
co-chair,
who
may
feel
differently,
but
I'd
be
perfectly
happy
to
see
this
it.
You
know,
move
on
move
into
T's
and
D
conflict
and-
and
you
know
it's
informational,
so
it
helps
people
understand
what
to
do
so.
You
know
we
don't.
The
ITF
doesn't
like
producing
those
types
of
the
documents,
but
that's
okay.
We
can
produce
them
to
problem.
T
I
think
we've
heard
a
couple
of
times
this
week.
Where
people
talk
about
yeah,
we
do
Solutions
Kurt.
Sorry,
we
do
tools
great.
We
don't
do
solutions
really
well
on.
This
is
more
a
solutions
thing
and
I'm.
Okay,
I'm,
okay,
with
again
personally
I
can't
speak
for
my
co-chair,
who
may
feel
differently.
I'm
happy
see
this.
This
move
over
to
T's
and
I
mean
you
got
to
make
sure
you're
not
saying
exactly
the
same
thing
as
another
document.
You
can
give
a
little
summary
and
say:
go
read
here
for
details.
T
J
T
Concepts
are
from
a
conceptual
standpoint.
The
fundamental
concepts
are
the
same.
The
specific
technologies
being
references
referenced
are
different.
So
that's
why
I
think
there's
room
for
the
work
right
if
it
was
a
if
it
was
completely
completely
duplicated,
I
would
just
say
this
is
already
done.
Thanks
see
you
later,
but
that's
that
was
my
comment.
Yeah.
T
I
C
C
C
L
The
first
one
is
those
carries
a
net
and
we
use
the
term
as
a
non-transparent,
because
there
are
some
seen
either
between
the
client
and
the
transport
network,
and
the
other
section
will
be
the.
We
call
this
other
transport
network
client
signal,
but
we
turned
this
as
transparent,
because
it's
a
signal
directly
coming
to
the
transport
tunnel
siendo
with
outer
switching
as
a
client
layer,
so
we
use
the
next.
Please.
L
You
know
we
try
to
explain
this
kind
of
transparent
and
non
transparent
by
looking
at
the
data
applying
features
of
the
client
signal
and
for
the
transparent
ones.
We
do
not
need
to
switch
as
a
client
layer.
Therefore,
we
do
not
need
tunnel
model
as
a
client
layer,
of
course,
and
the
topology
model.
L
We
only
provides
access
links,
information
that
it
would
be
sufficient
and
for
this
kind
of
kindness
signals,
the
key
feature
is
we
only
have
point
point
and
port
base
mapping
and
the
signal
directly
come
into
the
transport
tunnel
and
comes
out
to
the
comes
out
at
the
other
end,
so
the
both
end
have
the
same
crying
signal,
type
rate
and
the
Cody.
So
that
means
we
just
need
to
reuse
the
transport
tunnel
and
to
carry
a
signal
and
the
typical
example
for
transparent
turn
signal
includes
a
sdh/sonet,
Sun
storage
and
ethernet
phy.
L
So
for
this
kind
of
kind
of
signal
types,
the
parameters
need
to
be
configured
include
both
the
kind
signal
type
and
the
access
link
information.
So
we
need
a
mapping
next,
please,
and
the
model
here
exactly
shows
how
it
is
defined
and
so
on.
The
perspective
of
the
transporter
knows
we
need
to
understand
what
the
signal
type
is
by
carrying
here
and
what
has
our
access
information
by
some
other
parameters?
Next,
please,
and
for
non-transparent
resistance,
are
slightly
more
complicated
and
that's
we
just
have
one
typical
examples.
L
As
camera
is
a
net
which
includes
EPR,
EVP
are
applying
a
Petri
and
so
on
so
forth.
So
this
non
transparent
kind
of
signals
have
the
following
features:
it
can
be
P,
2,
P,
NP,
2,
MP
or,
and
the
access
links
have
the
same
kind
signal
type
still
Ethernet,
but
they
can
have
different
ways
and
encoding
and
they
can
be
splitted
into
different
transport
Hanno's.
But
this
is
more
packet
phase
matching
rather
than
support
based.
So
we
can.
We
need
to
kind
of
relearn
classification
and
operations
needed.
L
There
is
no
tunnel
model
needed
again,
so
tomorrow,
models
are
also
similar
with
the
previous
one.
We
provide
to
the
access
links.
That
would
be
good
enough
and
we
have
a
candidate
draft
on
this
one
and
in
the
non
transparent
kind
signal
the
parameters
need
to
be
configured
besides
the
basic
ones.
We
also
need
to
include
some
explicit
Ethernet
service
features.
Next,
please,
so
here
is
what
we
specified
the
for
the
this
kind
of
non
transparent
signals,
the
first
group
it's
about
the
isn't,
a
specific
attributes.
L
This
is
a
quite
isn't
as
specific,
and
then
it
is
a
basic
information
which,
which
is
means.
So
what?
What
is
the
name
description
and
the
types
of
the
service
and
finally
it
so
how
it
is
accessed
to
the
transport
handle.
So
this
is
similar
to
the
previous
one
next
and
finally,
there
is
a
possibility
that
we
can
introduce
the
Ethernet
crying
tunnel
when
we
really
need
to
be
switched
on
the
client
layer.
L
So
the
key
features
of
Ethernet
crying
tunnel
would
be
it's
a
hot
based
and
we
need
to
do
this
kind
of
kind
of
switching.
So
in
this
case
we
need
the
topology
and
Tunnel
model
for
for
the
client
signals,
and
we
have
to
can
they
draft
here?
Actually,
they
are
augmenting
to
the
teeth
of
all
the
NT
tunnel
models
respectively,
and,
if
you
remember
the
previous
OT
in
draft,
there
would
be
issues.
L
S
I'm
gonna
make
a
comment
almost
verbatim
to
lose.
So
basically,
I
think.
What
we
really
need
is
a
framework
generic
framework
about
how
we
map
services
on
Chi
Tunnels,
ok,
which
which
should
not
be
dependent
on
particular
technology
and
whatever
you
do.
It's
it's
very
good,
and
we
have
to
do
this
for
specific
signals
and
stuff
like
that
here
right,
but
but
we
need
a
framework
that
describes
that
here's,
the
services
current
from
clients
and
here's
the
provider
tunnel,
so
no
matter
which
layers
are
and
how
you
map
the
tunnels
on
to
the
services
in.
L
S
Ability
yeah
I'm,
not
I'm,
talking
about
much
bigger
document,
it's
afraid.
So,
for
example,
we
discuss
it
with
news
kochiya
whisper
on
a
particular
use
case
when
a
network
operator
wanted
to
control
which
backup
tunnel
protects,
which
connection
in
the
USA
in
IP
network.
Ok,
it's
basically
the
same.
It's
the
same
thing.
We
have
backup
tunnels
and
we
have
services
in
a
form
of
connection
that
needs
to
be
protected.
Ok,
so
how
do
you
actually
go
to
the
PLR,
ok
and
and
till
here?
S
This
connection
should
be
protected
by
this
backup
tunnel,
but
this
two
connection
by
that
backup
tunnel.
Ok,
it's
exactly
the
same,
like
you
would
say:
here's
how
do
you
put
there
say
you
know
pseudo
wire
signal
or
whatever
the
private
appeal
on
this
tunnel,
auto
on
to
that,
ok
and
and
on
the
tunnels.
S
You
would
consider
all
kind
of
key
consideration,
but
on
the
place
where
the
surest
some
weapon
to
the
tunnel
is
just
basically
the
preference
of
the
client
and
the
policies
which
is
very
different,
but
but
it
has
nothing
to
do
with
a
particular.
It's
all
the
same
for
for
different
technologies
as
well.
This
is
still
for
the
consulate
for
for
the
device.
S
Configuration,
but
it
is
basically
whether
it's
PE
or
whether
it's
ethernet
device
or
whatever
you
want
to
say:
okay,
III
provision
or
provision
on
demand
those
channels
and
now
I
want
to
map
services,
just
like,
for
example,
in
in
layer
3.
You
know
they
almost
have
this
right.
They
have
the
tea
tiles,
they
have
their
free
model
which
describes
the
service
network
white,
and
then
they
have
another
model
which
basically
says
how
to
put
like
a
particularly
piensan.
S
N
H
D2L
or
Nokia
yeah,
my
understanding
of
this
strategy
is
that
it
is
very
technology
specific,
so
it
actually
describes
how
to
map
Ethernet
correlated
services
into
the
OTN,
for
example.
What
I've
also
noticed
is
that
most
of
the
service
parameters
are
not
new.
There
are
well
known
and
I'm
wondering
well.
Those
parameters
are
coming
from
like,
for
example,
the
evil,
eb
LAN
services
or
part
based
services,
and
also
the
like
the
CR
and
and
then
the
other
parameters,
I'm
missing
references
to
existing
work,
because
I
I
build
it.
This
is
not
new.
A
H
L
Well,
we
are
going
to
align
it
with
other
organizations,
but
Internet
is
only
by
example,
but
we
have
two
young
files
in
this
document
wise
for
the
Carrier
Ethernet
as
non
transparent,
as
the
other
is
for
other
kinds
of
like
transparent
for
transparent
I
think
it
is
quite
simple
and
complete,
but
for
Ethernet
we
need
some.
You
know:
alignment
with
other
STL,
so
yeah
yeah,
yeah.
D
Thank
you
to
comment
what
the
ego
was
saying.
Ten
would
like
to
clarify
that
these
models
are
assuming
the
T
topology
Model
T
tunnel
model,
but
the
the
client-side
is
a
very
specific
technology
specific
as
deter
is
saying
because
we
have
tried
those
in
the
past
and
we
don't
have
a
common
ground
between
the
different
layer,
one
and
layer,
two
and
also
layer
tree
will
be
completely
different.
So
we
we
focus
on
the
specific,
and
then
we
say
this
visit.
S
C
K
Okay,
so,
basically,
with
this
draft,
which
is
a
still
experimental,
we
would
like
to
address
a
pretty
simple
problem
related
to
the
SSO
and
network
has
been
addressed.
Some
part
of
this
technology
by
the
76
76
99
98
and
77
92.
What
is
missing,
of
course,
is
what
is
missing
is
the
definition
of
the
carrier
contained
in
the
media
channel
and
then
the
signaling
of
the
position
of
the
carrier
and
the
kind
of
the
carrier
you
want
to
the
control
plane
may
decide
to
use.
K
Compared
to
the
previous
version
document,
there
are
very
few
changes.
We
just
split
the
pot
identifier
in
a
source
and
destination
port,
95
and
I
know
I
shaped
a
little
bit
to
the
chapters.
The
novelty
here
is
just
not
related
to
this
document,
but
is
more
related
to
information
coming
from
the
itu-t,
the
G
media
and
UNF,
so
that
we
we
see
that
let's
go
directly
to
this
light.
Okay,
we
see
that
the
definition
coming
from
from
ITT
is
matching
this
slide
and
they
are
defined.
K
The
relationship
between
OTS
I,
the
carrier
and
what
is
a
carrier
by
carried
by
the
OTS
I
group.
Let's
say
what
you
say
is
the
set
of
the
different
OTS
I
working
together,
and
so
what
we
discuss
a
little
bit
among
some
people
that
are
in
this
room
on
the
G,
media
and
I
believe
we
are
not
that
far
from
the
G
media
definition
apart.
K
The
terminology,
of
course,
so
my
opinion
is
that
we
should
continue
this
discussion
and
we
should
let
say,
keep
very
careful
attention
to
what
what's
going
on
in
the
media,
because
they
are
doing
something
interesting
and
they
are
addressing
the
real
problem
that
is
made
in
in
this
way.
Let's
say
so:
let's
keep
all
the
details.
K
The
next
step
is
to
really
follow
the
a
to
T
and
onf
development
in
terms
of
models
and
in
terms
of
definition,
just
to
make
sure
that
with
we
are
still
in
line
on
on
that
models,
of
course,
feedbacks
and
comments.
But
last
but
not
least,
I
would
like
to
have
this
document
as
working
with
document,
because
I
think
we
need
all
together
working
on
that
and
and
across
this
let's
say
we
kick
point
off
of
the
call
or
not
address
point
of
this
technology.
I
hope
get
back.
Some
notes.
Ok,.
K
C
K
O
E
E
You
know
it's
already
around
since
a
while
again
lmps
really
not
about
configuration.
I,
always
repeat
it
because
sometimes
falls
on
this
idea
of
using
lmpd
to
configure
something.
But
these
LMP
draft
is
really
about
to
understand
what
are
the
limitations
between
two
nodes
which
are
connected
by
a
piece
of
fiber,
so
change
from
the
previous
version?
We
basically
just
update
a
little
bit
of
references
and
there's
also
but
an
interesting
thing,
because
the
draft
has
been
kind
of
disputed
in
the
past,
because
there
was
no
power
monitor
available
in
in
the
ITU
documents.
E
While
this
draft,
for
example,
it
asks
to
supervise
whether
a
let's
say
light
comes
in
or
not.
So
what
is
the
power
level
your
you?
Don't
really
get
on
a
receive
end,
so,
fortunately
enough
IQ.
Is
there
there's
now
an
optical
power
monitor
as
a
function
that
monitors
you
have
to
get
power
in
one
or
more
media
channels?
And
that's
thank
you
fully.
The
demo.
E
E
E
So
you
see
everything
is
about
power
here,
that's
why
it
was
so
important
to
get
the
2017
version
of
g8
72,
so
that
kept
us
here.
Okay,
now
again,
next
steps
is
we
still
need
to
update
a
little
bit
of
the
references,
because
there's
so
much
things
than
going
on
particular
at
you
side,
and
so
we
would
like
to
ask
to
make
this
now
a
working
group
document
based
on
the
new
definitions
on
g7.
C
C
C
E
Okay,
next
one
is
WDM
interface
parameter,
it's
a
it's
kind
of
a
companion
draft,
but
this
one
talks
about
the
young
model
that
goes
together
really
lumpy.
Again
it
has
the
kind
of
same
changes,
same
updates,
we're
keeping
them
aligned.
So
the
assumption
is
ready
to
go
together.
Whatever
the
decision.
C
E
Comment,
what
was
WDM
invented
by
the
way,
all
right,
so
this
is
about
the
it's
really
about
the
next
further
extension
of
LMP.
So
this
is
why
we
put
it
on
a
on
a
different
graph
about
the
next
great.
So
again,
the
same
considerations
apply.
This
is
not
about
configuring
anything.
This
is
about
figuring
out
what,
as
the
other
end
remote
and
supports.
When
you
connect
it
parameters
to
change,
you
see,
there's
a
there's
a
lot
more
again.
This
is
about
the
Flex
rate.
E
It's
also,
for
example,
modulation
scheme,
so
it
seems
to
identify
what
is
the
other
end
doing
so
don't
go
through
all
those
details.
I
can
have
a
look
at
the
draft,
so
we
are
fixing
here
again
some
references,
there's
not
much
update
here
and
we
keep
the
line,
though
so
with
the
without
the
efforts
in
NCCAM
and
will
also
focus
on
operational
aspects,
meaning
it
should
be
really
simple
to
use
a
rather
than
let's
just
solve
everything
in
a
very
complex
pair
again.
E
This
goes
together
also
with
a
back
draft,
which
is
the
young
model,
and
it
also
has
is
about
the
the
validation
of
the
impairments.
Again.
This
is
kind
of
providing
a
consistent
way
to
operate.
Wavelengths
interfaces
with
net
conveying
changes,
it's
it
can
update,
so
we're
we're
waiting
for
itu
to
giving
us
the
interface
parameters
to
agree
upon
and
we
keep
it
aligned,
there's
also
an
alignment
where
the
draft
ITF
secant
obvious
on
IV
info
and
the
ib
encode,
so
we'll
probably
follow
the
fade
over
there.
E
L
It's
good
your
patient,
however
Pilate
III
read
your
side
saying
that
keep
alignment
always
the
two
working
group
draft
up,
also
IV,
but
I
want
to
clarify
about
that.
I
think
the
working
group
draft
IV
focus
on
the
impairment
between
the
SS
and
RS.
Yes,
it
seems
that
your
document
is
focus
on
something
around
long-term.
Only
so.
B
E
L
L
P
P
Yeah,
here's
the
history
of
this
document.
It
was
submitted
last
year
and
submit
to
the
ISS
working
group
and
president
I
ETA
F
98,
and
this
Excel
is
received
some
comments
and
at
least
major
to
major
one
too
many
comments
here.
The
first
one
about
home
of
this
is
were
very
common
sight.
This
work
should
belong
to
this
working
group,
so
we
take
that
comments
and
relay
the
document
and
submit
to
the
second
group.
The
second
one
is
about
usage
of
the
theories
based
on
which
theory
to
to
carry
the
flag
ceiling
attributes.
P
So
as
at
the
very
beginning,
we
proposed
to
use
the
interface
which
in
capability
theory
to
to
carry
the
flag
ceiling
attributes,
but
there's
some
point
that
they
said
they
that
heavy
is
fun
to
describe
the
interface
switching
capability,
and
this
is
not
about
flexi.
Switching,
so
I
would
decide
not
use
that
curvy
and
if
I
try
to
defend
neutral
between
to
carry
the
flag
ceiling
attributes.
P
So
here's
some
terminology
used
in
this
document,
the
first
one
is
flexi
interface.
So,
as
we
know,
flexi
can
support
funding
and
translation
and
subgrade.
So
a
flex
interface
is
a
logical
funding
interface
that
can
also
consist
of
from
1
to
250
for
a
Gigabit
Ethernet
interface
and
a
flexi.
Sub
interface
is
a
generalized
interface
of
an
inter
flex
interface
and
so
for
the
flat
ceiling,
and
that
is
a
linear
connect
to
flex
interfaces,
and
also
the
effects
of
a
link
is
a
link
that
connects
to
fact
C
sub
interfaces.
P
So
here's
the
extension
I
think
it's
very
straightforward
with
just
different
sub
curvy,
which
is
called
flexi
interface,
observe
it
today
extended
eyes,
eyes,
reachability.
Clearly
this
it
is
too
quite
defined,
described,
attribute
of
effect
interface
as
an
example
to
carry
the
flag
secret
members
tilt
to
the
granularity
of
our
slot
and
volleyball
on
snorts
of
an
interface.
P
And
also
this
about
flexi
sub-link
advertisement,
basically
of
lack
discipline,
can
be
trader,
can
be
considered
as
a
lot
more
easily
trimmed,
but
sometimes
for
some
scenarios,
and
it
may
be
useful
to
indicate
whether
a
pass
a
link
is
a
channelized
flexi
link.
Then
the
computer,
the
container
or
unload
can
use
that
information.
The
computer
pass
that
is
required
to
over
flexi
link.
So
we
we
try
to
define
or
introduce
a
new
flag
to
the
link
attribute
to
indicate
when
flooding
is
a
link
we
come
in
used
indicate.
P
C
M
M
M
M
As
far
as
I
understand,
the
Oh
aspects
is
that
plexi
is
not
really
visible
to
anything
any
layers
above
Ethernet,
it
looks
to
the
upper
layers
like
each
and
now
what
we're
saying
is
we're
going
to
expose
the
details
of
it
into
a
routing
protocol
to
be
able
to
configure
it.
So
how
do
we
reconcile
that.
P
W
So,
in
addition
to
linear
protection
and
rim
protection,
G
I
Tod
that
Emily
808
Doc's
redefines
our
generic
and
aspects
for
the
shared
mesh
protection
and
based
on
that
G
top
eight
seven.
Three
top
three
also
defines
the
protection,
switching
operation
and
IPS
protocols
for
SMP
a
two
audio
layer.
So
this
new
draft
is
trying
to
update
the
FC
or
eight
seven,
two
to
provide
extensions
to
the
gem,
fair
signaling,
to
support
the
control
of
shared
mesh
protection.
W
Look
at
the
SMP
introduction,
so
in
order
to
some
in
order
to
describe
the
shared
mesh
protection,
we
can
use
three
characters
to
describe
that.
The
first
one,
the
for
the
shared
mesh
protection
resources,
are
reserved
for
the
protection
SP
at
her
provisioning
stage,
but
the
crossed
necks
of
the
protection
osteon
not
pre-established.
A
second
point:
the
common
link
know
the
resources
of
protecting
LSP
can
be
shared
by
multiple
physically
disjointed
working
outs,
peace
and
some
point.
When
the
working
SP
fails,
the
APS
messages
will
be
used
to
trigger
the
protection,
SP
and
executive
protection.
W
W
W
W
So
for
the
primary
RSP
during
the
provisioning,
we
are
going
to
add
a
new
airspeed
protection
type
share,
image,
protection
and
also,
in
addition
to
as
bait
and
PP
beat
in
this
SMP
page.
We
also
set
an
update,
so
the
other
things,
for
example
a
position
ID
or
we
were
used
the
same
way
as
SMR.
We
were
at
the
associati
to
indicate
the
secondary,
protecting
our
speed
and
during
the
protection
switching
stage,
which
means
we
upped
the
protection
switching.
W
For
the
signalling
of
the
second
secondary
LSP
is
the
same
as
the
working
air
speed
during
the
provisioning
stage.
We
also
add
a
new
protection
type
shared
mesh
protection
and
we
also
set
the
impeach
and
the
other
things,
for
example,
associating
ID
and
the
we
all
use
the
same
way
as
SMR
and
in
order
to
resource
sharing,
we
will
also
include
a
primary
pass
route
in
the
past
message
for
the
setup
of
seminary
SP
and
then
during
the
protection
switching
stage,
which
means
same
after
protection,
so
itchy
I'm.
Sorry
during
the
work
protection
switching
stage.
W
Firstly,
the
protection
switching
will
be
triggered
by
the
APS
protocol
in
the
data
plane,
so
that
is
a
main
difference
from
the
SMR
and
then
after
protection.
Switching,
we
will
refresh
the
past
message
with
the
OPIC
set,
which
means
we
were
the
the
the
seminary
SP
will
become
the
parameter,
so
that
is
signalling
of
the
second
area
speak
and
as
a
summary,
these
are
the
updates
to
the
protection
object.
So
for
the
firstly,
we
will
add
a
new
protection
type
under
those
P
flags.
W
It's
about
this
one
shared
mesh
shared
mesh
protection
and
for
the
notification
and
the
operation
paints
a
bit.
We
will
add
SMP
case
a
currently.
It's
only
mentioned
the
one-to-one
1+1
protection,
but
for
shared
mesh
protection.
We
will
also
use
these
two
bits:
okay,
next
step.
Since
it's
a
serial
version
drop
this
a
new
dropped.
We
would
like
to
get
feedbacks
from
the
working
group
level
and
see
how
we
move
forward.
Okay,.
O
W
B
B
W
W
A
H
D2
Bell
Nokia
shared
mesh
protection
is
the
most
complicated
protection
scheme
I've
ever
seen.
I
guess
what
we
did
in
the
past
when
we
will
define
signals,
are
starting
to
define
gmpls
signaling
extensions
for
mechanisms.
We
developed
a
framework
document
that
also
described
the
mechanism.
It
also
described
how
it's
applied
and
it
also
described
scenarios
how
it
should
be
how
it
should
work.
I
think
this
is
required
for
this
protection
scheme.
W
H
I
think
we
need
a
separate
document.
The
framework
document
is
that
describes
the
shared
mesh
protection
mechanism,
how
it
works.
What
the
motivation
is
to
define
signaling
extensions
for
setting
up
or
configuring
the
network
elements
that
are
part
of
shared,
that
shared
measure
protection
group,
because
I
believe
that,
in
the
shared
mesh
protection
group,
all
the
network
elements
there
are
members
of
this
group
need
to
be
configured.
C
F
A
T
T
It's
the
same
protocol,
it's
all
about
media
channels,
but
the
media
channel
here
are
as
focused
that
at
the
RF
layer,
but
it's
the
same
stuff,
so
I'm
talking
about
work
that
I've
been
was
actually
started
by
other
folks,
but
I
got
involved
with
and
been
helping
out
with.
So
we
have
four
documents
in
the
men:
a
working
group
that
our
post
last
call
three
of
them
are
with
the
co-authors.
T
T
There
was
one
technical
change
that
we
thought
it
was
important
to
mention,
but
it
souls
preceding
the
technical
change
was
basically
it.
The
comment
came
from
actually
doing
an
implementation
of
a
part
of
the
protocol.
Strange
thing
is
yeah
we're
the
routing
area
and
we
actually
tried
to
implement
stuff
before
we
fully
standardized
it.
So
that
happened
here
and
out
of
the
implementation
recognized
that
there
was
an
inconsistency
in
how
we
did
our
definition
of
sub
data
item
sub
tell
TLD
sub
objects
whatever
you
want
to
call
it.
T
It's
all
the
same
thing
in
the
the
first
order,
sub
tlvs
again
data
items
indeed
laugh
had
the
till
these
nut.
Sub-Q
Epis
haddock
by
definition,
were
unordered
and
we
did
our
sub
TLV
definition
ordered,
and
that
was
inconsistent
and
because
of
that
inconsistency
it
actually
meant
that
we
couldn't
just
reuse
the
same
mechanisms
in
the
same
parsing
code
and
the
same
structural
elements.
Work
for
describing
packets
that
were
used
in
the
rest
of
the
implementation
and
I
say
we
here.
I
had
nothing
to
do
with
it.
T
It's
actually
David
Wiggins
over
at
MIT,
and
because
of
that
there
was
a
comment
that
came
back,
went
went
through
it.
We
said:
okay,
this
is
the
right
change.
Other
we've
discussed
it
on
the
list
that
everyone
said
yeah.
This
is
a
really
good
thing
and
we
made
the
change
to
a
while
for
an
order
that
had
some
consequences
on
the
contents
of
the
sub
data
item.
That's
it
but
we're
post
last
call.
We
expect
that
to
be
any
day
now
come
out
of
the
Shepherd,
hopefully
safe.
T
The
ones
that
are
really
active
are
based
are
focused
on
credit
based
flow
control.
Remember
I
said
this
is
really
different
and
what
we're
trying?
What
we're
doing
here
is
is
we
have
credit
windows
between
a
router
and
an
attached
modem
and
we
use
different
flow
control
mechanisms.
This
one
is
a
credit
one.
The
reason
that
we
use
credits
is
it's.
T
We
had
a
bunch
of
discussions
about
how
to
structure
these
documents,
because
we
had
some
core
mechanisms
that
were
being
defined
and
then
being
you
used
at
the
time.
Just
for
packets,
identified
really
by
flow,
is
identified
by
DSC
P's
and
we
wanted
to
say
well,
maybe
that's
not
the
only
way
we
want
to
identify.
We
want
to
identify
them
also
by
Ethernet
and
tomorrow.
I
know,
Rick
has
some
other
way.
He
wants
to
identify
things.
He
hasn't
told
us
yet
what
they
are.
T
The
actual
mechanisms
you're
using
on
a
particular
session
like
LDP
deal
app
is
has
a
stateful
peering
relationship,
and
you
know
what
your
peer
does
and
we're
saying
at
a
time
you
want
to
be
able
to
indicate
whether
or
not
we're
doing
dscp
base
flow
control
or
Ethernet
based
flow
control,
so
the
core
mech
mechanisms
are
in
the
DEA
credit
extension,
there's
really
two
interesting
parts
to
that.
The
first
is
is
a
traffic
classification
construct,
which
is
how
you
you
build
out
your
traffic
classifiers.
T
Q
T
Q
Q
T
T
T
T
So
Igor
is
asking:
why
am
I
discussing
it
and
is
it
merging
I
completely
defer
to
the
area
directors
on
this?
Frankly,
personally,
I
think
this
meeting
highlighted
by
about
to
a
75
to
80
degree
that
they
shouldn't
be
together,
but
that's
not
my
call
I'll
go
wherever
they
say,
LMP
LMP,
with
an
extra
letter.
That's
what
it
is
the
reality
is
is
this
should
have
been
now
they
started
around
they've
been
around.
Both
protocols
been
around
a
long
time
deal.
F
is
a
little
younger.
T
T
Group
document,
because
that's
we've
always
been
doing
credit
extensions
Ethernet,
hasn't
gone
through
a
adoption
poll.
So
that's
why
it's
a
draft
Berger.
Obviously,
if
you
did
a
split,
it
would
continue
to
be
a
working
group
document.
If
it's
been
a
Stan
gets
to
hit
okay.
If
it's,
if
it's
C
camp,
we
got
to
reissue
all
these
anyway.
T
T
We
had
a
couple
of
technical
changes
as
part
of
the
split
one
of
the
things
we
did
is
originally
we
were
looking
at
the
the
Ethernet
data
item
is
being
fixed
length
rather
than
variable
like
the
reason
for
that
is
with
a
fixed
length.
You
don't
have
to
worry
about
the
special
case
and
padding
of
nibbles.
The
reason
why
we've
now
moved
a
variable
length
is
because
everything
else
in
the
protocol
is
variable
length,
and
it
was
the
only
place
that
had
fixed
like
that.
I
didn't
make
sense
to
do
that.
T
We
also
clarified
that
the
scope
and
sub
data
items
are
the
data
item
within
which
they
reside
and
noted
in
the
registry
that
that's
the
way
it
should
be
all
right.
So
the
first
thing
that
we
want
to
do
is
confirm
the
split,
and
what
we've
seen
is
is
that
the
split
wasn't
far
enough
and
we'll
split
again.
T
Q
Have
a
customer,
the
Ethernet
credit
yeah
I'm,
the
last
one
from
me.
There
was
a
personal
draft.
Somebody
checked
in
I
think
from
Cisco
India
about
five
years
ago
about
trying
to
wedge
VLANs
into
develop
they.
If
they're
listening,
I
think
it
was.
It
wasn't
quite
the
right
way
to
go.
I
know
you've
got
your
VLAN
IDs
in
their
eyes.
My
question
was:
did
you
while
putting
that
together,
look
at
using
vids
without
the
tossed
marking
part
so
saying
I
just
want
to
split
on
the
VLANs
I,
don't
give
it.
T
So
it
does,
does
it
cool
and
it
talks
about
exactly
how
to
do
that.
You
know
basically,
vid
has
to
be
there
because
that's
where
the
tag
it
has
to
be
there
in
order
to
carry
the
the
code
points
and
if
you're
carrying
the
tag,
you
got
to
know
whether
or
not
what
the
bid
value
is.
Even
if
it's
zero,
you
still
need
it
just.
V
One
quick
comment:
this
is
staying
around
off.
I
I
agree
with
you
that
these
documents
are
good
and
I
agree
with
you
that
they
should
be
accepted,
I'm,
just
not
sure
if
we
can
make
any
movement
on
that
until
we
figure
out.
Based
on
your
comments
of
you
know
a
couple
hours
ago,
we
we've
got
to
make
that
bigger
decision.
First
right.
T
Q
X
This
stove
has
not
been
actually
decided
yet,
so
we
will
step
run
for
the
need,
echo
people
so
yeah
we
haven't
actually
decided
formally.
Yet
it
looks
right
now
like
it
will
come
to
see
camp.
So
so
we'll
we'll
continue
then,
hopefully,
in
about
a
month
I'd
say
this
should
be
resolved.
Okay,.
T
That'd
be
great
in
terms
of
where
we
are
in
the
technical
solution.
We
we
think
the
technical
solution
is
pretty
solid.
We've
been
looking
at
it,
some
implementations
and
Rick,
and
we
had
some
offline
conversation
about
actually
how
to
get
the
traffic
control
piece
to
work
inside
the
Linux
kernel.
So
we
think
that
we
can
get
this
an
open
source
implementation
out
there
and.
X
Deborah
again,
and
if
it
comes
to
secant,
the
reason
it's
coming
is
because
we
are
the
experts
on
LMP.
So
I
would
encourage
you,
even
if
you
don't
think
you're
interested
in
this.
You
know
take
a
look
at
it
and
help
them
technically
to
to
improve
this
and
to
give
input,
and
you
may
learn
something
from
it
and.
T
We'd
really
appreciate
additional
comments,
and
is
there
anyone
in
the
room
who
has
not
raised
their
hand
during
this
slot
who's
willing
to
take
a
look
at
these
documents
at
provide
comment?
Is
there
anyone
interested
all
right?
You
get
the
prize,
it's
a
free
admission
to
the
social
I'm,
not
joking,
we
want
we,
you
know.
Sometimes
we
bribe
people.
Q
H
T
T
Q
T
T
Works
for
me,
you
know
just
as
long
as
the
work
is
proceeding.
We
have
people
that
care
about
it
and
so
we'll
we'll
wait.
I
guess
in
terms
of
a
recap
of
steps,
we'll
wait
to
hear
what
goes
on
what
goes
on.
I
would
suggest
that
we
do
the
split
as
the
first
set
in
the
first
C
camp:
zero,
zero
versions.
Just
so
we
don't
have
to
confuse
things
and
then
well.
This
will
obviously
need
to
be
pulled.
The
challenge
is
you're.
Gonna
get.
You
know
five
people
who
have
an
opinion
on
this.
Okay.
C
C
C
Flexi
am
flexible
transponders
where
we
dynamic
dynamically
are
allowed
to
change
format,
modulation
format
and,
in
fact,
if
I
could
remember,
there
were
some
concerns
about
the
usage
of
feed
state
machines.
These
concerns
should
be
raised
against
the
the
generic
model
are
the
one
that
has
been
presented
in
that
motor,
and
here
we
should
focus
on
the
technology
specific
extensions.
So
please
have
a
look
at
the
draft
main
mean
changes
with
respect
to
the
last
version
that
the
previous
version
regard
the
synchronization.
C
Basically,
when
at
the
field
state
machine
changes
on
a
node,
we
need
to
have
the
other.
You
know
that
the
other
end
synchronized
and
the
impacter
on
on
the
right
of
the
transponder,
that
is
that
is
used.
So
please
have
a
look
at
the
document.
Please
have
a
look
at
the
generic
field
state
machine
document
that
is
in
that
one.
E
J
Actually,
I
think
the
right
step
is
defined:
transponder,
augmenting
TTP
in
the
theater
Paula
G
and
then
maybe
work
on
state
on
that.
But
this
I
talk
to
Nicola
offline.
Actually,
we
are
proposing
some
some
longer
total
ego
as
well.
So
we
need
to
have
more
base
model
that
model
a
transponder
and
then
you
know
other
stuff
first
and
then
most
likely
I
think
next
idea
we
have
that
draft
and
then
Nicola
might
be
with
the
co-authors
of
that
I
kind
of
told.
J
J
B
J
W
son
impairment,
model
I
think
that's
probably
more
relevance,
because
why
you
care
about
transponder
and
modulation
because
of
impairment
right
so
I
think
my
proposal
is,
you
know,
impairment
model,
has
this
transponder
aspects,
augmenting,
ttp
and
then
characterize
some
of
the
behaviors
there?
Is
that
acceptable?
Yes,.