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

[Julien Meuric <[e-mail]>]

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 >
[e-mail] https://www.ietf.org/mailman/listinfo/ccamp >