Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd

Ramon Casellas <ramon.casellas@cttc.es> Thu, 14 May 2015 09:22 UTC

Return-Path: <ramon.casellas@cttc.es>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6AD41AC41B for <ccamp@ietfa.amsl.com>; Thu, 14 May 2015 02:22:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.559
X-Spam-Level: ***
X-Spam-Status: No, score=3.559 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.157, J_CHICKENPOX_12=0.6, MANGLED_FORM=2.3, T_HTML_ATTACH=0.01] 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 ssiSYFkv8xBb for <ccamp@ietfa.amsl.com>; Thu, 14 May 2015 02:22:12 -0700 (PDT)
Received: from navarro.puc.rediris.es (navarro.puc.rediris.es [IPv6:2001:720:418:ca01::131]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48E4F1ACEDE for <ccamp@ietf.org>; Thu, 14 May 2015 02:22:10 -0700 (PDT)
Received: from [2001:40b0:7c22:6020:78f1:9a85:af1c:f412] (helo=leo) by navarro.puc.rediris.es with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <ramon.casellas@cttc.es>) id 1YspLB-0006CF-K3 for ccamp@ietf.org; Thu, 14 May 2015 11:22:06 +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 E54471FD05 for <ccamp@ietf.org>; Thu, 14 May 2015 11:21:53 +0200 (CEST)
X-Envelope-From: ramon.casellas@cttc.es
Message-ID: <55546934.8070806@cttc.es>
Date: Thu, 14 May 2015 11:21:56 +0200
From: Ramon Casellas <ramon.casellas@cttc.es>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: ccamp@ietf.org
References: <4A1562797D64E44993C5CBF38CF1BE48128F2479@ESESSMB301.ericsson.se> <5550A8BC.4090005@labn.net> <9D50FCE7413E3D4EA5E42331115FB5BC29C85B6B@xmb-rcd-x03.cisco.com>
In-Reply-To: <9D50FCE7413E3D4EA5E42331115FB5BC29C85B6B@xmb-rcd-x03.cisco.com>
Content-Type: multipart/mixed; boundary="------------060803020706090102050806"
X-Spamina-Bogosity: Unsure
Archived-At: <http://mailarchive.ietf.org/arch/msg/ccamp/wV-s8n0CBNnMmuT5gyoEi8ffIYo>
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp/>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 May 2015 09:22:22 -0000

Dear Matt, all

Thank you very much for the review and comments, please see inline 
(aligned with Adrian's reply).

For what is worth, there were some comments that I received post LC, 
that will also be in next updated version.


El 12/05/2015 a las 0:02, Matt Hartley (mhartley) escribió:
>
> All,
>
> I’ve reviewed this revision of the document, and I think it’s almost 
> ready for publication. I have a few comments (below) but I don’t think 
> there’s any major issues.
>
> 3.1: definition of OTN could be moved up to section 2.2, if you want.
>
Ramon> Added as acronym, and removed the expansion, thank you
>
> 3.2.1: you state that the Nominal Central Frequency Granularity is 
> 6.25GHz, but there’s no reference for this. I assume it’s in an ITU 
> doc somewhere? If so, it’d be good to say so (and where)
>
Ramon> Indeed. Much like SWG being 12.5GHz, added [G.694.1]
>
> The document refers to “OTSi signals” in several places, but the 
> definition of “OTSi” includes “signal” :) I don’t know whether or not 
> this is normal usage or whether it’s worth fixing… but it looks 
> technically wrong to me (like people talking about “PIN numbers” 
> whenever they get cash out of the bank).
>
Ramon> changed OTSi signals to OTSi

> 3.2.5, first bullet: “This group of OTSi should be carried over a 
> single fibre.” Is that a normal English should, or a 2219 SHOULD? If 
> the former, it might be worth rephrasing to avoid ambiguity.
>
Ramon> changed to "are" as per Adrian's suggestion
>
> 4.2: “The association of the three components a filter, a fiber, and a 
> filter, is a media channel in its most basic form.”. It’d be nice to 
> clarify that this is a fiber with a filter at each end – that’s not 
> immediately obvious on first reading, especially with the diagram that 
> makes it clear on the next page.
>
Ramon> Likewise, changed to "association sequence"

> The paragraph below figure 8 is... unclear. Is it just trying to say 
> that media channels can be joined together to make a new media 
> channel? Or is there more to it than that?
>
Ramon> Basically the intent is that one, although it should reflect more 
to the join of "basic" media channels (defined as an association 
sequence of filter-fiber-filter as above). This, and the architectural 
construct being an LSP.  Changed to also use the term "association sequence"

OLD

    Additionally, when a cross-connect for a specific frequency slot is
    considered, the underlying media support is still a media channel,
    augmented, so to speak, with a bigger association of media elements
    and a resulting effective slot.  When this media channel is the
    result of the association of basic media channels and media layer
    matrix cross-connects, this architectural construct can be
    represented as (i.e., corresponds to) a Label Switched Path (LSP)
    from a control plane perspective.  In other words, It is possible to
    "concatenate" several media channels (e.g., Patch on intermediate
    nodes) to create a single media channel.


NEW

    Additionally, when a cross-connect for a specific frequency slot is
    considered, the resulting media support of joining basic media channels
    is still a media channel, i.e., a longer association sequence of media
    elements and its effective frequency slot. In other words, It is possible to
    "concatenate" several media channels (e.g., patch on intermediate
    nodes) to create a single media channel.

    The architectural construct resulting of the association sequence
    of basic media channels and media layer matrix cross-connects can be
    represented as (i.e., corresponds to) a Label Switched Path (LSP)
    from a control plane perspective.



> Fig 12: OTSi trail? Did you mean OCh trail?
>
Ramon> The error comes from the text, since the correct term is OTSi.

OLD

    In Figure 12 a Network Media Channel is represented as terminated at
    the DWDM side of the transponder.  This is commonly named as OCh-
    trail connection.

NEW

    In Figure 12 a Network Media Channel is represented as terminated at
    the network side of the transponders.  This is commonly named as OTSi-
    trail connection.


> Fig 14: MLN/MRN needs explaining. Or removing.
>
Ramon> Removed.
>
> 4.3, towards the end: “there must be enough guard band between 
> adjacent OTSis in any media channel to compensate filter concatenation 
> effect and other effects caused by signal layer switching elements”. 
> Maybe “…to compensate for the filter concatenation effect and…” or 
> “…to compensate for filter concatenation effects and…”?
>
Ramon> new text
"there must be  enough guard band between adjacent OTSis in any media 
channel to  compensate for the filter concatenation effects and other 
effects caused by signal layer switching elements"

> 4.8.4: bear in mind that 0 is not a positive integer, and it looks 
> like the definitions involving (2^n) and (2^m) are intended to include 
> the case where n/m is 0.
>
Ramon> Changed for "n" to say "non-negative integer". For "m", I am 
leaving it as positive integer, since m=0 would imply an empty frequency 
slot.


If no further comments, I will proceed to upload these changes for -04 
(with other backlogged changes such as affiliation changes, CCAMP WG, 
Informational, nits, editorial changes , typos, etc. ). Please see the 
attached diff


Thanks
Ramon