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

[<[e-mail]>]

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

Br
Rüdiger

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

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:[e-mail]] On Behalf Of Julien Meuric
Sent: martedì 2 maggio 2017 17:32
To: [e-mail]
Subject: 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 >
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 >


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

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