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

[Daniele Ceccarelli <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] 
Sent: venerdì 12 maggio 2017 12:38
To: [e-mail]
Cc: Daniele Ceccarelli <[e-mail]>; [e-mail]; [e-mail]
Subject: AW: [CCAMP] I-D Action: draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04.txt

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:[e-mail]]
Gesendet: Freitag, 12. Mai 2017 12:34
An: Kunze, Rüdiger
Cc: [e-mail]; [e-mail]; [e-mail]
Betreff: Re: [CCAMP] I-D Action: draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04.txt

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, "[e-mail]" <[e-mail]> ha scritto:
> 
> 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-fw
> k-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
> 
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp