Re: [CCAMP] Gen-ART review of draft-ietf-ccamp-flexi-grid-fwk-05 - Minor Issues
Ramon Casellas <ramon.casellas@cttc.es> Mon, 24 August 2015 09:36 UTC
Return-Path: <ramon.casellas@cttc.es>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7941AC3DB for <ietf@ietfa.amsl.com>; Mon, 24 Aug 2015 02:36:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.4
X-Spam-Level: *
X-Spam-Status: No, score=1.4 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_12=0.6] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7F8LrYeSZFa3 for <ietf@ietfa.amsl.com>; Mon, 24 Aug 2015 02:36:51 -0700 (PDT)
Received: from marchena.puc.rediris.es (marchena.puc.rediris.es [IPv6:2001:720:418:ca00::4]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 149371AC3D6 for <ietf@ietf.org>; Mon, 24 Aug 2015 02:36:51 -0700 (PDT)
Received: from [84.88.62.208] (helo=leo) by marchena.puc.rediris.es with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <ramon.casellas@cttc.es>) id 1ZToBJ-0005Pn-OR; Mon, 24 Aug 2015 11:36:47 +0200
Received: from [84.88.61.50] (unknown [84.88.61.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by leo (Postfix) with ESMTPSA id 67A701FEF4; Mon, 24 Aug 2015 11:36:41 +0200 (CEST)
X-Envelope-From: ramon.casellas@cttc.es
Subject: Re: [CCAMP] Gen-ART review of draft-ietf-ccamp-flexi-grid-fwk-05 - Minor Issues
To: ccamp@ietf.org
References: <CE03DB3D7B45C245BCA0D243277949361405374F@MX104CL02.corp.emc.com>
From: Ramon Casellas <ramon.casellas@cttc.es>
Message-ID: <55DAE5AB.5080704@cttc.es>
Date: Mon, 24 Aug 2015 11:36:43 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <CE03DB3D7B45C245BCA0D243277949361405374F@MX104CL02.corp.emc.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Spamina-Bogosity: Unsure
X-Spamina-Spam-Score: -0.2 (/)
X-Spamina-Spam-Report: Content analysis details: (-0.2 points) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4994]
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/yS9ax8c6h24XFH7YIhWoQV5r9Mk>
X-Mailman-Approved-At: Mon, 24 Aug 2015 08:04:33 -0700
Cc: "Black, David" <david.black@emc.com>, "ietf@ietf.org" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Aug 2015 09:36:52 -0000
Dear David, all Many thanks for your review and comments and I apologize for the delay, I was on holidays. Fortunately, Adrian and Fatai were kind enough to reply, and I am mostly aligned. Please see inline for comments Best regards Ramon El 04/08/2015 a las 16:20, Black, David escribió: > >> -----Original Message----- >> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >> Sent: Monday, August 03, 2015 1:38 PM (snip) >> >> You can make an end-to-end connection from a set of parallel channels. You can >> place those channels at different spots in the spectrum from one hop to the >> next, but you cannot vary the number of channels from one hop to the next (e.g. >> two channels on one hop mapped to one thick channel on the next hop mapped to >> four thin channels on the next hop). > Part of this is definitely my lack of GMPLS familiarity. That said, something > to make the "cannot vary the number of channels from one hop to the next" point > would be helpful to add. Perhaps: > > OLD > That is, the slot composition must be the same from one > end to the other of the media channel even if the specific slots > and their spacing may vary hop by hop. > NEW > That is, the slot composition (i.e., the group of OTSi carried by > the composite media channel) must be the same from one > end to the other of the media channel even if the specific slot > for each OTSi and the spacing among slots may vary hop by hop. Ramon> Changed, as per your suggestion. Thanks. >>> [2] p.21 last sentence in 1st para: >>> >>> >>> Should "minimum frequency slot width" be "minimum effective frequency slot >>> width"? I think it's possible for the effective frequency slot width to >>> be smaller than all of the individual slot widths involved in the absence >>> of frequency shifters/converters. Ramon> Indeed, it is possible, notably when central frequencies differ. As Adrian mentions, adding effective is ok, will appear in next version. Added >>> [3] p.21 - RSA acronym is unfortunate, due to collision w/widespread usage >>> >>> In most cases of acronym collision, I would not object, but RSA is unusual as >>> a very widely known security algorithm acronym (and there are a small number of >>> other acronyms, whose reuse I would find problematic, e.g., SSL and TLS). I >>> still think RSA is a rather poor choice of acronym for routing functionality, >>> no matter how well it's explained. Ramon> I fully understand your concerns, but I am afraid that I tend to disagree, the RSA acronym is also quite well understood in optical networking, and R&SA, RSA, R+SA, etc. can have different meanings. I am willing to hear other opinions, but I would not change it. >>> [5] 5.5 - I'm surprised that the first requirement (neighbor discovery >>> support) is a MAY. I wonder about its operational consequences, and at the >>> very least suggest expanding Section 8 to discuss them. The text in 5.5 >>> should be expanded to add some explanation of how things work when there's >>> no neighbor discovery support. >> Although some work has been done on plug and play in transport networks, there >> is also a lot of "legacy" thought with respect to plugging 100G fibers in at >> random and seeing what is connected to what today. In general, when one >> provisions a fiber and a pair of expensive line cards, one has a good idea what >> one is connecting and the processes that are run are validation rather than >> discovery. >> >> Thus the second paragraph aims for link property correlation such as is provided >> in LMP, but the first paragraph only considers the element of discovery to be >> something that someone could look at if they are really enthusiastic. >> >> Since this is pretty much established behavior across GMPLS optical networks, >> I'm not sure more needs to be said. > Please state that absence of neighbor discovery is "pretty much established > behavior across GMPLS optical networks" perhaps in the form of "not required > or used in common operational practice." Ramon> What about OLD The control plane MAY include support for neighbor discovery such that an flexi-grid network can be constructed in a "plug-and-play" manner. NEW The control plane MAY include support for neighbor discovery such that an flexi-grid network can be constructed in a "plug-and-play" manner. Note, however, that in common operational practice validation processes are used rather than automatic discovery. Related email follows on nots and editorial.... Thanks again Ramon
- RE: [CCAMP] Gen-ART review of draft-ietf-ccamp-fl… Black, David
- Re: [CCAMP] Gen-ART review of draft-ietf-ccamp-fl… Ramon Casellas
- RE: [CCAMP] Gen-ART review of draft-ietf-ccamp-fl… Black, David