Subject: [CCAMP] G.698.2 drafts way forward

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 24 Mar 2015 19:44:02 +0000

Dear authors of G.698.2 draft,

This is a follow up of my comment to your presentations in CCAMP. I checked the minutes of the IETF91 meeting (http://tools.ietf.org/wg/ccamp/minutes?item=minutes-91-ccamp.html) and, assuming the power was removed from the list of managed parameters, the WG showed good interest in working on the topic.

I see the power was not removed from the drafts and I was wondering what are you plans. Are you willing to keep it in it or available to get rid of it?

BR
Daniele

---

From: <[email-masked]>
Date: Thu, 26 Mar 2015 21:37:30 +0100

Hi Daniele,

we agree to remove the transmit power settings from LMP and from the SNMP MIB documents. Regarding the power reading, we believe that this is a needed parameter to verify  the maximum channel power difference as specified in  G. 692 (Table 7): "This recommendation specifies the possibility of loss between reference points S and Rm" as per figure 1/G.692.
We will update and re-submit the document right after this IETF meeting. With this latest update we believe to address all the concerns of the working group and if there are no further objections we can proceed with acceptance as WG documents.

BR

The authors of the drafts

Gabriele, Gert and Ruediger

Von: CCAMP [mailto:[email-masked]] Im Auftrag von Daniele Ceccarelli
Gesendet: Dienstag, 24. März 2015 20:44
An: CCAMP ([email-masked])
Betreff: [CCAMP] G.698.2 drafts way forward

BR
Daniele

---

From: Dieter Beller <[email-masked]>
Date: Thu, 26 Mar 2015 22:48:17 +0100

Hi all,

here are my 2 cents:

The exchange of power values between adjacent NEs does IMHO only
make sense, if there is a use case that justifies this and an

application/procedure that needs these values as input parameters.

Application codes as defined in G.698.2 do currently define Tx and
Rx power value ranges at reference points Ss and Rs, respectively.

A power level control loop that adjusts power levels such that the
input/output power range at the reference point stays within

the given range could be an example of a use case/application that
may require the exchange of the current input/output values.

The draft does not provide a reasonable use case nor does it
describe an application/procedure that makes use of these values.
So,

there is a gap which IMHO needs to be filled before we can decide
whether to keep the exchange of power level values or whether

they should be removed.

Thanks,

Dieter

On 26.03.2015 21:37, [email-masked]
wrote:

Hi
Daniele,

we
agree to remove the transmit power settings from LMP and
from the SNMP MIB documents. Regarding the power reading, we
believe that this is a needed parameter to verify  the
maximum channel power difference as specified in  G. 692
(Table 7): “This recommendation specifies the possibility of
loss between reference points S and Rm” as per figure
1/G.692.

We
will update and re-submit the document right after this IETF
meeting. With this latest update we believe to address all
the concerns of the working group and if there are no
further objections we can proceed with acceptance as WG
documents.

BR

The
authors of the drafts

Gabriele,
Gert and Ruediger

Von:
CCAMP [mailto:[email-masked]] Im Auftrag von
Daniele Ceccarelli

Dear authors of G.698.2
draft,

This is a follow up of
my comment to your presentations in CCAMP. I checked the
minutes of the IETF91 meeting (http://tools.ietf.org/wg/ccamp/minutes?item=minutes-91-ccamp.html)
and, assuming the power was removed from the list of managed
parameters, the WG showed good interest in working on the
topic.

I see the power was not
removed from the drafts and I was wondering what are you
plans. Are you willing to keep it in it or available to get
rid of it?

BR

Daniele

_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: <[email-masked]>
Date: Fri, 27 Mar 2015 00:36:17 +0100

Dieter,

We assume you are referring to http://tools.ietf.org/id/draft-dharinigert-ccamp-g-698-2-lmp-09.txt and invite you to review the introduction part. More 'exotic' use cases like control loops would require a read and a write operation for power levels. However in particular the write operation was considered unsuitable by the optical experts commenting in the past. We would certainly appreciate if you could point us to ITU-T Recommendations supporting such a use case and in particular to an information model supporting write operations of power levels.

BR

Rüdiger

Von: Dieter Beller [mailto:[email-masked]]
Gesendet: Donnerstag, 26. März 2015 22:48
An: Kunze, Rüdiger; [email-masked]; [email-masked]
Cc: [email-masked]
Betreff: Re: [CCAMP] G.698.2 drafts way forward

Hi all,

here are my 2 cents:

The exchange of power values between adjacent NEs does IMHO only make sense, if there is a use case that justifies this and an
application/procedure that needs these values as input parameters.

Application codes as defined in G.698.2 do currently define Tx and Rx power value ranges at reference points Ss and Rs, respectively.

A power level control loop that adjusts power levels such that the input/output power range at the reference point stays within
the given range could be an example of a use case/application that may require the exchange of the current input/output values.

The draft does not provide a reasonable use case nor does it describe an application/procedure that makes use of these values. So,
there is a gap which IMHO needs to be filled before we can decide whether to keep the exchange of power level values or whether
they should be removed.

Thanks,
Dieter
On 26.03.2015 21:37, [email-masked]<mailto:[email-masked]> wrote:
Hi Daniele,

BR

Von: CCAMP [mailto:[email-masked]] Im Auftrag von Daniele Ceccarelli
Gesendet: Dienstag, 24. März 2015 20:44
An: CCAMP ([email-masked]<mailto:[email-masked]>)
Betreff: [CCAMP] G.698.2 drafts way forward

BR
Daniele

CCAMP mailing list

[email-masked]<mailto:[email-masked]>

---

From: Dieter Beller <[email-masked]>
Date: Fri, 27 Mar 2015 16:19:50 +0100

Hi Rüdiger, all,

I discussed the issue with Gabriele this morning and we reached an
agreement how to move forward.

One of the use cases we discussed this morning is monitoring the
power level on the ROADM sided that requires knowledge of the

current Tx power value at the Ss reference point. Together with the
knowledge of the attenuation of the fiber link between Ss and

a power monitoring point on the ROADM side, it is possible to
calculate the expected power level at this measurement point which

can then be used to monitor the received power level. If it drops
below a certain threshold, an alarm can be raised. The same thing

is also possible in reverse direction.

Gabriele is going to work on a description of these use cases. We
also draw a figure that could be added to the draft illustrating the

use cases.

If required, we may also have to suggest IM extensions supporting
these use cases - this still remains to be seen.

Thanks,

Dieter

On 27.03.2015 00:36, [email-masked]
wrote:

Dieter,

We
assume you are referring to http://tools.ietf.org/id/draft-dharinigert-ccamp-g-698-2-lmp-09.txt
and invite you to review the introduction part. More
‘exotic’ use cases like control loops would require a read
and a write operation for power levels. However in
particular the write operation was considered unsuitable by
the optical experts commenting in the past. We would
certainly appreciate if you could point us to ITU-T
Recommendations supporting such a use case and in particular
to an information model supporting write operations of power
levels.

BR

Rüdiger

Von:
Dieter Beller [mailto:[email-masked]]

An: Kunze, Rüdiger;
[email-masked]; [email-masked]

Hi
all,

here are my 2 cents:

The exchange of power values between adjacent NEs does IMHO
only make sense, if there is a use case that justifies this
and an

application/procedure that needs these values as input
parameters.

Application codes as defined in G.698.2 do currently define
Tx and Rx power value ranges at reference points Ss and Rs,
respectively.

A power level control loop that adjusts power levels such
that the input/output power range at the reference point
stays within

the given range could be an example of a use
case/application that may require the exchange of the
current input/output values.

The draft does not provide a reasonable use case nor does it
describe an application/procedure that makes use of these
values. So,

there is a gap which IMHO needs to be filled before we can
decide whether to keep the exchange of power level values or
whether

they should be removed.

Thanks,

Dieter

Hi
Daniele,

we
agree to remove the transmit power settings from LMP and
from the SNMP MIB documents. Regarding the power reading,
we believe that this is a needed parameter to verify  the
maximum channel power difference as specified in  G. 692
(Table 7): “This recommendation specifies the possibility
of loss between reference points S and Rm” as per figure
1/G.692.

We
will update and re-submit the document right after this
IETF meeting. With this latest update we believe to
address all the concerns of the working group and if there
are no further objections we can proceed with acceptance
as WG documents.

BR

The
authors of the drafts

Gabriele,
Gert and Ruediger

Von:
CCAMP [mailto:[email-masked]]
Im Auftrag von Daniele Ceccarelli

Dear authors of
G.698.2 draft,

This is a follow up of
my comment to your presentations in CCAMP. I checked the
minutes of the IETF91 meeting (http://tools.ietf.org/wg/ccamp/minutes?item=minutes-91-ccamp.html)
and, assuming the power was removed from the list of
managed parameters, the WG showed good interest in working
on the topic.

I see the power was
not removed from the drafts and I was wondering what are
you plans. Are you willing to keep it in it or available
to get rid of it?

BR

Daniele

CCAMP mailing list

[email-masked]

--

DIETER
BELLER

ALCATEL-LUCENT
DEUTSCHLAND AG

PROJECT MANAGER ASON/GMPLS CONTROL PLANE

IP ROUTING AND TRANSPORT BL

IP TRANSPORT BU

Lorenzstrasse 10

70435 Stuttgart, Germany

Phone: +49 711 821 43125

Mobil: +49 175 7266874

[email-masked]

Alcatel-Lucent
Deutschland AG

Domicile of the Company: Stuttgart · Local Court Stuttgart HRB
4026

Chairman of the Supervisory Board: Michael Oppenhoff

Board of Management: Wilhelm Dresselhaus (Chairman) · Hans-Jörg
Daub · Ralf Niederberger

This e-mail and its attachments, if any, may contain
confidential information.

If you have received this e-mail in error, please notify us and
delete or destroy the e-mail and its attachments, if any,
immediately.

If you have received this e-mail in error, you must not forward
or make use of the e-mail and its attachments, if any.

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 27 Mar 2015 15:34:28 +0000

Hi Dieter, Gabriele, all,

I'm very happy to hear about that. Thanks for finding the time discuss and finding an agreement.

We're looking forward to seeing an updated version of the draft soon.

Thanks
Daniele

From: Dieter Beller [mailto:[email-masked]]
Sent: venerdì 27 marzo 2015 10:20
To: [email-masked]; Daniele Ceccarelli; [email-masked]
Cc: [email-masked]
Subject: Re: AW: [CCAMP] G.698.2 drafts way forward

Hi Rüdiger, all,

I discussed the issue with Gabriele this morning and we reached an agreement how to move forward.

One of the use cases we discussed this morning is monitoring the power level on the ROADM sided that requires knowledge of the
current Tx power value at the Ss reference point. Together with the knowledge of the attenuation of the fiber link between Ss and
a power monitoring point on the ROADM side, it is possible to calculate the expected power level at this measurement point which
can then be used to monitor the received power level. If it drops below a certain threshold, an alarm can be raised. The same thing
is also possible in reverse direction.

Gabriele is going to work on a description of these use cases. We also draw a figure that could be added to the draft illustrating the
use cases.

If required, we may also have to suggest IM extensions supporting these use cases - this still remains to be seen.

Thanks,
Dieter

On 27.03.2015 00:36, [email-masked]<mailto:[email-masked]> wrote:
Dieter,

BR

Rüdiger

Von: Dieter Beller [mailto:[email-masked]]
Gesendet: Donnerstag, 26. März 2015 22:48
An: Kunze, Rüdiger; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Betreff: Re: [CCAMP] G.698.2 drafts way forward

Hi all,

here are my 2 cents:

Thanks,
Dieter

BR

BR
Daniele

CCAMP mailing list

--
DIETER BELLER
ALCATEL-LUCENT DEUTSCHLAND AG
PROJECT MANAGER ASON/GMPLS CONTROL PLANE
IP ROUTING AND TRANSPORT BL
IP TRANSPORT BU

Lorenzstrasse 10
70435 Stuttgart, Germany
Phone: +49 711 821 43125
Mobil: +49 175 7266874
[email-masked]<mailto:[email-masked]>

Alcatel-Lucent Deutschland AG
Domicile of the Company: Stuttgart · Local Court Stuttgart HRB 4026
Chairman of the Supervisory Board: Michael Oppenhoff
Board of Management: Wilhelm Dresselhaus (Chairman) · Hans-Jörg Daub · Ralf Niederberger

This e-mail and its attachments, if any, may contain confidential information.
If you have received this e-mail in error, please notify us and delete or destroy the e-mail and its attachments, if any, immediately.
If you have received this e-mail in error, you must not forward or make use of the e-mail and its attachments, if any.