Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04.txt

From: Julien Meuric <[email-masked]>
Date: Tue, 2 May 2017 17:32:29 +0200

Hi all,

Following the presentation in Chicago, I had a look a this I-D. I am
supportive of the initiative behind this document, but this version does
not look ready to go to the IESG yet. Please find my comments below.

Probably due to pieces of text written by different contributors (which
is good), the scope of the document is really unclear, starting from the
introduction:
- "ROADMs" and "control" are mentioned, as well as "combination of
transport and packet infrastructures to ensure high availability and
flexible data transport", "demand for a new wavelength from A to Z", etc;
- after a couple of paragraph we end up with "pre-configured [...]
network connections", a figure with just "OADM", a "solution space"
focusing on "physical point-to-point and ring DWDM applications", etc.
I am hoping a framework about to be published by CCAMP intends to be
generic enough to include dynamic control, but there is some
inconsistency in the current text.

Similarly, the control introduced multiple times along with management
ends up as management only, e.g. in Section 3 ("Solution Space").

In 3.1.2, I am puzzled with the sentence "Even a in that case a common
north bound management interface is required to ensure a consistent
management of the entire connection":
- I guess the first "a" is a typo,
- what is "North bound" referring to?
- why "management" only? Thanks to the introduction of LMP, the
following paragraph realizes it is also about "control", but consistency
should be there from the beginning;
- is that section trying to circumvent phrases like "multi-vendor
consistency"? What about "In that case, operations of the end-to-end
connection requires consistent management/control between the line and
the transponders"? (The phrase "management/control" may help addressing
several of my comments above.)

The split introduced in section 4.1 is confusing. It seems to be mixing
the logical part, i.e. what entity the client device needs to talk to,
and the physical part, i.e. the DCN architecture (which may rely on a
direct link between the client device and the transport node, whatever
the logical scenario). A simple way to address this comment is to keep
the split at the logical level, as suggested by the figures, thus
implying to:
- drop the odd paragraph trying to define the DCN in section 4.1.1 ["The
exchange... MCC)."] and replace it by a simple sentence like: "The
connectivity supporting that management traffic requires that the client
device is connected to the optical DCN, e.g., through a dedicated access
or the neighbor transport node (this is deployment-specific and is
beyond the scope of this document)."
- rephrase the (wrong) title of section 4.1.2, e.g. "Direct
Communication with the First Optical Node";
- replace "other signalling communication channel (SCC or IPCC)"
(unnecessary jargon) by "any relevant DCN connectivity".

In section 4.2:
- I do not really follow the sentence "The general GMPLS control plane
for wavelength switched optical networks is work under definition in the
scope of WSON." It may be replaced by "GMPLS control protocols have been
extended for WSON, e.g. [RFC7689] for fixed grid signaling and [RFC7792]
for flexi-grid."
- I guess "BL" refers to "Black Link" but it is never defined; at this
stage, it seems easier to avoid the acronym and expand it everywhere;
- typo: s/it is internal facilities/its internal facilities/
- the introduction packages the wavelength as part of the black link
information and mentions LMP only as a control protocol: does it suggest
that encompassing the lambda label into LMP is considered?

Section 4.2.1 is highly relevant in CCAMP, but I believe we should here
limit the use of the "UNI" and "overlay" terms to prevent confusion.
This would lead to "Considerations using GMPLS Signaling" as a title,
the following reference being acceptable. I would also either drop the
confusing parenthesis "(overlay will be transformed to a border-peer
model)", or change it into "(i.e. a border peer model, see RFC 5146)".
Then, in options to proceed, I would add "RSVP-TE (typically with loose
ERO)" in both a. and b. For grammar consistency, b. should be rephrased
as: "b. Using RSVP-TE (typically with loose ERO) to transport additional
information".
The section ends on pointing out 2 issues, but the 2nd one ("b") is
already addressed by draft-ietf-teas-network-assigned-upstream-label.
The corresponding paragraph should thus be updated, e.g.:
"b) Due to the bidirectional wavelength path that must be setup, the
upstream edge node must include a wavelength value in the RSVP-TE Path
message. The special value defined in
[draft-ietf-teas-network-assigned-upstream-label] allows the optical
network to assign the actual wavelength to be used by the upstream
transponder, which is a simple and efficient way to address this issue."

Usually, use case sections help understanding/motivating the remainder
of the documents. Here, I am not so sure about section 5: even though I
am familiar with the process in my company, there a a few things I do
not follow, e.g. when referring to a single vendor WDM network through
the black link model. Some details should also be fixed, e.g., what the
OXCn is referring to or "this LMP draft".

Moreover, in the requirement list of section 6:
- req. 7 (FRR trigger) is implementation-specific, it should not be in
an IETF document (as opposed to using, for instance, RFC 4209 to report
a BER in a legacy deployment);
- req. 10 says "pre-tested", which is operation-specific, and
"configured", which is network-specific: operators must be free to
deploy recovery mechanism the way the choose to, some may rely on
control plane-based rerouting, some may prefer preventing recovery in
the optical layer;
- RSVP-TE is missing from the requirements, though mentioned several
times: how about adding "RSVP-TE may be used to exchange some relevant
parameters between the client and the optical node (e.g. the label
value), without preventing the optical network to remain in charge of
the optical path computation"? [As req. 7, it would avoid renumbering. ;-) ]

Finally, it feels like there are too many normative references for an
informative framework: many of them should be moved to the informative
section.

Regards,

Julien

Mar. 13, 2017 - :
> A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Common Control and >
Measurement Plane of the IETF. > > Title           : A framework for
Management and Control of DWDM > optical interface parameters
Authors         : Ruediger Kunze Gert > Grammel Dieter Beller Gabriele
Galimberti Filename        : >
draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04.txt Pages           : 29 >
Date            : 2017-03-13 > > Abstract: To ensure an efficient data
transport, meeting the > requirements requested by today's IP-services
the control and > management of DWDM interfaces is a precondition for
enhanced > multilayer networking and for an further automation of
network > provisioning and operation. This document describes use cases
and > requirements for the control and management of optical interfaces
> parameters according to different types of single channel DWDM >
interfaces.  The focus is on automating the network provisioning >
process irrespective on how it is triggered i.e. by EMS, NMS or >
GMPLS.  This document covers management as well as control plane >
considerations in different management cases of single channel DWDM >
interfaces.  The purpose is to identify the necessary information >
elements and processes to be used by control or management systems > for
further processing. > > > The IETF datatracker status page for this
draft is: >
https://datatracker.ietf.org/doc/draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk/
There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04 > > A diff from the previous version is available at: >
https://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04
Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: >
ftp://ftp.ietf.org/internet-drafts/ > >
_______________________________________________ CCAMP mailing list >
[email-masked] https://www.ietf.org/mailman/listinfo/ccamp >

---

From: Fatai Zhang <[email-masked]>
Date: Fri, 5 May 2017 03:51:54 +0000

Hi Julien,

Thanks very much for your careful review, and I believe that the authors will discuss your comments on the list and address them soon.

Thanks

Fatai

-----邮件原件-----
发件人: CCAMP [mailto:[email-masked]] 代表 Julien Meuric
发送时间: 2017年5月2日 23:32
收件人: [email-masked]
主题: Re: [CCAMP] I-D Action: draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04.txt

Hi all,

Following the presentation in Chicago, I had a look a this I-D. I am supportive of the initiative behind this document, but this version does not look ready to go to the IESG yet. Please find my comments below.

Probably due to pieces of text written by different contributors (which is good), the scope of the document is really unclear, starting from the
introduction:
- "ROADMs" and "control" are mentioned, as well as "combination of transport and packet infrastructures to ensure high availability and flexible data transport", "demand for a new wavelength from A to Z", etc;
- after a couple of paragraph we end up with "pre-configured [...] network connections", a figure with just "OADM", a "solution space"
focusing on "physical point-to-point and ring DWDM applications", etc.
I am hoping a framework about to be published by CCAMP intends to be generic enough to include dynamic control, but there is some inconsistency in the current text.

Similarly, the control introduced multiple times along with management ends up as management only, e.g. in Section 3 ("Solution Space").

In 3.1.2, I am puzzled with the sentence "Even a in that case a common north bound management interface is required to ensure a consistent management of the entire connection":
- I guess the first "a" is a typo,
- what is "North bound" referring to?
- why "management" only? Thanks to the introduction of LMP, the following paragraph realizes it is also about "control", but consistency should be there from the beginning;
- is that section trying to circumvent phrases like "multi-vendor consistency"? What about "In that case, operations of the end-to-end connection requires consistent management/control between the line and the transponders"? (The phrase "management/control" may help addressing several of my comments above.)

The split introduced in section 4.1 is confusing. It seems to be mixing the logical part, i.e. what entity the client device needs to talk to, and the physical part, i.e. the DCN architecture (which may rely on a direct link between the client device and the transport node, whatever the logical scenario). A simple way to address this comment is to keep the split at the logical level, as suggested by the figures, thus implying to:
- drop the odd paragraph trying to define the DCN in section 4.1.1 ["The exchange... MCC)."] and replace it by a simple sentence like: "The connectivity supporting that management traffic requires that the client device is connected to the optical DCN, e.g., through a dedicated access or the neighbor transport node (this is deployment-specific and is beyond the scope of this document)."
- rephrase the (wrong) title of section 4.1.2, e.g. "Direct Communication with the First Optical Node";
- replace "other signalling communication channel (SCC or IPCC)"
(unnecessary jargon) by "any relevant DCN connectivity".

In section 4.2:
- I do not really follow the sentence "The general GMPLS control plane for wavelength switched optical networks is work under definition in the scope of WSON." It may be replaced by "GMPLS control protocols have been extended for WSON, e.g. [RFC7689] for fixed grid signaling and [RFC7792] for flexi-grid."
- I guess "BL" refers to "Black Link" but it is never defined; at this stage, it seems easier to avoid the acronym and expand it everywhere;
- typo: s/it is internal facilities/its internal facilities/
- the introduction packages the wavelength as part of the black link information and mentions LMP only as a control protocol: does it suggest that encompassing the lambda label into LMP is considered?

Section 4.2.1 is highly relevant in CCAMP, but I believe we should here limit the use of the "UNI" and "overlay" terms to prevent confusion.
This would lead to "Considerations using GMPLS Signaling" as a title, the following reference being acceptable. I would also either drop the confusing parenthesis "(overlay will be transformed to a border-peer model)", or change it into "(i.e. a border peer model, see RFC 5146)".
Then, in options to proceed, I would add "RSVP-TE (typically with loose ERO)" in both a. and b. For grammar consistency, b. should be rephrased
as: "b. Using RSVP-TE (typically with loose ERO) to transport additional information".
The section ends on pointing out 2 issues, but the 2nd one ("b") is already addressed by draft-ietf-teas-network-assigned-upstream-label.
The corresponding paragraph should thus be updated, e.g.:
"b) Due to the bidirectional wavelength path that must be setup, the upstream edge node must include a wavelength value in the RSVP-TE Path message. The special value defined in [draft-ietf-teas-network-assigned-upstream-label] allows the optical network to assign the actual wavelength to be used by the upstream transponder, which is a simple and efficient way to address this issue."

Usually, use case sections help understanding/motivating the remainder of the documents. Here, I am not so sure about section 5: even though I am familiar with the process in my company, there a a few things I do not follow, e.g. when referring to a single vendor WDM network through the black link model. Some details should also be fixed, e.g., what the OXCn is referring to or "this LMP draft".

Moreover, in the requirement list of section 6:
- req. 7 (FRR trigger) is implementation-specific, it should not be in an IETF document (as opposed to using, for instance, RFC 4209 to report a BER in a legacy deployment);
- req. 10 says "pre-tested", which is operation-specific, and "configured", which is network-specific: operators must be free to deploy recovery mechanism the way the choose to, some may rely on control plane-based rerouting, some may prefer preventing recovery in the optical layer;
- RSVP-TE is missing from the requirements, though mentioned several
times: how about adding "RSVP-TE may be used to exchange some relevant parameters between the client and the optical node (e.g. the label value), without preventing the optical network to remain in charge of the optical path computation"? [As req. 7, it would avoid renumbering. ;-) ]

Finally, it feels like there are too many normative references for an informative framework: many of them should be moved to the informative section.

Regards,

Julien

Mar. 13, 2017 - :
> A New Internet-Draft is available from the on-line Internet-Drafts > 
> directories. This draft is a work item of the Common Control and >
transport, meeting the > requirements requested by today's IP-services the control and > management of DWDM interfaces is a precondition for enhanced > multilayer networking and for an further automation of network > provisioning and operation. This document describes use cases and > requirements for the control and management of optical interfaces
> parameters according to different types of single channel DWDM >
interfaces.  The focus is on automating the network provisioning > process irrespective on how it is triggered i.e. by EMS, NMS or > GMPLS.  This document covers management as well as control plane > considerations in different management cases of single channel DWDM > interfaces.  The purpose is to identify the necessary information > elements and processes to be used by control or management systems > for further processing. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk/
There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04 > 
> > A diff from the previous version is available at: >
> until the htmlized version and diff are available at tools.ietf.org. > 
> > Internet-Drafts are also available by anonymous FTP at: >
ftp://ftp.ietf.org/internet-drafts/ > >
_______________________________________________ CCAMP mailing list > [email-masked] https://www.ietf.org/mailman/listinfo/ccamp >

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

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 12 May 2017 09:47:58 +0000

Hi authors,

could you please discuss the changes proposed by Julien on the mailing list so that we can move the draft forward?

Thanks a lot
Daniele  

-----Original Message-----
From: CCAMP [mailto:[email-masked]] On Behalf Of Julien Meuric
Sent: martedì 2 maggio 2017 17:32
To: [email-masked]
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04.txt

Hi all,

In section 4.2:

Regards,

Julien

---

From: <[email-masked]>
Date: Fri, 12 May 2017 10:18:14 +0000

Hi Daniele,
i will discuss the points directly with Julien.

Br
Rüdiger

-----Ursprüngliche Nachricht-----
Von: CCAMP [mailto:[email-masked]] Im Auftrag von Daniele Ceccarelli
Gesendet: Freitag, 12. Mai 2017 11:48
An: [email-masked]
Cc: [email-masked]
Betreff: Re: [CCAMP] I-D Action: draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04.txt

Hi authors,

Thanks a lot
Daniele  

-----Original Message-----
From: CCAMP [mailto:[email-masked]] On Behalf Of Julien Meuric
Sent: martedì 2 maggio 2017 17:32
To: [email-masked]
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04.txt

Hi all,

In section 4.2:

Regards,

Julien

---

From: "Gabriele Maria Galimberti (ggalimbe)" <[email-masked]>
Date: Fri, 12 May 2017 10:34:10 +0000

Hi Julien and Ruediger,
Shall we set a quick call?

Best Regards,
Gabriele

Inviato da iPhone

> Il giorno 12 mag 2017, alle ore 12:30, "[email-masked]" <[email-masked]> ha scritto:
> 
> Hi Daniele,

---

From: <[email-masked]>
Date: Fri, 12 May 2017 10:38:20 +0000

Hi Gab,
I sent Julien an E-Mail, to discuss and his points.
My proposal to update the document based on his points and then having a call. Your support is appreciated and all the other authors as well.
Im waiting for Juliens response and then i will send an invitation for a call.

Br,
Rüdiger

-----Ursprüngliche Nachricht-----
Von: Gabriele Maria Galimberti (ggalimbe) [mailto:[email-masked]] 
Gesendet: Freitag, 12. Mai 2017 12:34
An: Kunze, Rüdiger
Cc: [email-masked]; [email-masked]; [email-masked]
Betreff: Re: [CCAMP] I-D Action: draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04.txt

Hi Julien and Ruediger,

Best Regards,
Gabriele

Inviato da iPhone

> Betreff: Re: [CCAMP] I-D Action: 
> draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04.txt
> 
> Hi authors,
> 
> Subject: Re: [CCAMP] I-D Action: 
> draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04.txt
> 
> Hi all,
> 
> Probably due to pieces of text written by different contributors 
> (which is good), the scope of the document is really unclear, starting 
> from the
> introduction:
> following paragraph realizes it is also about "control", but 
> consistency should be there from the beginning;
> the transponders"? (The phrase "management/control" may help 
> addressing several of my comments above.)
> 
> Then, in options to proceed, I would add "RSVP-TE (typically with 
> loose ERO)" in both a. and b. For grammar consistency, b. should be 
> rephrased
> an IETF document (as opposed to using, for instance, RFC 4209 to 
> report a BER in a legacy deployment);
> network > provisioning and operation. This document describes use 
> cases and > requirements for the control and management of optical 
> interfaces
> elements and processes to be used by control or management systems > 
> for further processing. > > > The IETF datatracker status page for 
> this draft is: > 
>> https://tools.ietf.org/html/draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04 
>> >
>> until the htmlized version and diff are available at tools.ietf.org. 
>> >

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 12 May 2017 12:44:45 +0000

Hi Rudiger,

thanks for initiating the discussion.
Would it be possible to have it via mail on the list or to have a summary of your call on the list before updating the draft?
This is a WG document and every member of the working group should be involved or at least made aware of the changes. 

Thanks
Daniele  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: venerdì 12 maggio 2017 12:38
To: [email-masked]
Cc: Daniele Ceccarelli <[email-masked]>; [email-masked]; [email-masked]
Subject: AW: [CCAMP] I-D Action: draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04.txt

Hi Gab,

Br,
Rüdiger

-----Ursprüngliche Nachricht-----
Von: Gabriele Maria Galimberti (ggalimbe) [mailto:[email-masked]]
Gesendet: Freitag, 12. Mai 2017 12:34
An: Kunze, Rüdiger
Cc: [email-masked]; [email-masked]; [email-masked]
Betreff: Re: [CCAMP] I-D Action: draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04.txt

Hi Julien and Ruediger,

Best Regards,
Gabriele

Inviato da iPhone

---

From: Fatai Zhang <[email-masked]>
Date: Wed, 31 May 2017 07:36:01 +0000

Hi Rudiger and authors,

Could you update the WG on how to address the comments from Julien? 

BTW, Prague meeting is coming, :-)

Thanks

Fatai

-----邮件原件-----
发件人: CCAMP [mailto:[email-masked]] 代表 Daniele Ceccarelli
发送时间: 2017年5月12日 20:45
收件人: [email-masked]; [email-masked]
抄送: [email-masked]; [email-masked]
主题: Re: [CCAMP] I-D Action: draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04.txt

Hi Rudiger,

Thanks
Daniele  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: venerdì 12 maggio 2017 12:38
To: [email-masked]
Cc: Daniele Ceccarelli <[email-masked]>; [email-masked]; [email-masked]
Subject: AW: [CCAMP] I-D Action: draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04.txt

Hi Gab,

Br,
Rüdiger

-----Ursprüngliche Nachricht-----
Von: Gabriele Maria Galimberti (ggalimbe) [mailto:[email-masked]]
Gesendet: Freitag, 12. Mai 2017 12:34
An: Kunze, Rüdiger
Cc: [email-masked]; [email-masked]; [email-masked]
Betreff: Re: [CCAMP] I-D Action: draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04.txt

Hi Julien and Ruediger,

Best Regards,
Gabriele

Inviato da iPhone