Re: [CCAMP] Fwd: slides for draft-ietf-ccamp-flexi-grid-fwk-01

Cyril Margaria <cyril.margaria@gmail.com> Thu, 06 March 2014 09:40 UTC

Return-Path: <cyril.margaria@gmail.com>
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 3B5431A01AF for <ccamp@ietfa.amsl.com>; Thu, 6 Mar 2014 01:40:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level:
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] 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 06z9xHotVkJ2 for <ccamp@ietfa.amsl.com>; Thu, 6 Mar 2014 01:40:21 -0800 (PST)
Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id DE66F1A019A for <ccamp@ietf.org>; Thu, 6 Mar 2014 01:40:20 -0800 (PST)
Received: by mail-wg0-f51.google.com with SMTP id k14so355624wgh.22 for <ccamp@ietf.org>; Thu, 06 Mar 2014 01:40:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GWMUlGMxzGAummtBFij4UmIJ4C5IC3Jg1eoRnyrRklU=; b=BJSq9/5uL81CCHJkrnRe7PsUG4SmvvSQ6VXJJ9FazjqAD+ioWQMzFro1D36o8CCqxy sivrAELttZnRJfqf+1/20HtSNu4RbC3h9mdf7kDSZmFDZ+OCVf9jgr9WevSvUzWIfRvk O6VfWOLdnLm1bW3FsUXjwcPZblq5hlsDUwH+4gd7Ls7+9ZJe9XmvOyfjPquQoZIHhd9A KYbE1brC16UTr0VXbse6JIr+xyhXGLapMhcPcL/ieAk0tJTs/AS12cOqxC7uNAdY7zLr VX/LtJzi0E+2TEm4Dqa7uk9vnnRAs/JtJXquP6ojt/eK4PmhnBw476KF+COLDWpRwzPA Qj7Q==
MIME-Version: 1.0
X-Received: by 10.194.85.168 with SMTP id i8mr8094263wjz.81.1394098816441; Thu, 06 Mar 2014 01:40:16 -0800 (PST)
Received: by 10.216.61.12 with HTTP; Thu, 6 Mar 2014 01:40:16 -0800 (PST)
In-Reply-To: <DF3E7F96-18B8-443D-996E-C5770DCEED36@tid.es>
References: <OF28272013.7A147740-ON48257C91.004AA039-48257C91.004B16C0@zte.com.cn> <5315EB33.9040403@cttc.es> <D62E6669B3621943B7632961308F8F9E3BCC30A9@lhreml509-mbx> <5316D23F.10505@cttc.es> <D62E6669B3621943B7632961308F8F9E3BCC3567@lhreml509-mbx> <DF3E7F96-18B8-443D-996E-C5770DCEED36@tid.es>
Date: Thu, 06 Mar 2014 10:40:16 +0100
Message-ID: <CADOd8-t9TQii4cLps8pYHwdo=OVgmaU4tbvP_KyCaEV6ENb6Jg@mail.gmail.com>
From: Cyril Margaria <cyril.margaria@gmail.com>
To: Oscar González de Dios <ogondio@tid.es>, Maarten vissers <maarten.vissers@huawei.com>
Content-Type: multipart/alternative; boundary="089e010d7efcbcfab404f3ecec61"
Archived-At: http://mailarchive.ietf.org/arch/msg/ccamp/WPRLJNL2XsMyMP3N0ABeEIOapHc
Cc: "ccamp@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] Fwd: slides for draft-ietf-ccamp-flexi-grid-fwk-01
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, 06 Mar 2014 09:40:25 -0000

Hi,

The current framework document scope the LSP to the media channel, not any
OTU or OTUCn. The signal and adaptation part was out-of-scope in the
previous revisions. I did not see any change related to this configuration
in the document.
It is not immediately clear why the LSP should represent one optical
channel connection and not limit itself to the media channel.
This seems going into how the optical channel/termination is done.

I  do not see an immediate need to go in the termination part, the document
allows one LSP to carry several media-channel, encompassing all the media
channel needed to carry the optical channel.

I think that the current text address correctly the problem and
requirements for the current (public) data plane specs.

BR




On 5 March 2014 14:53, Oscar González de Dios <ogondio@tid.es> wrote:

>  FYI
>
> Enviado desde mi iPhone
>
> Inicio del mensaje reenviado:
>
>  *De:* Maarten vissers <maarten.vissers@huawei.com>
> *Fecha:* 5 de marzo de 2014 13:47:43 GMT
> *Para:* Ramon Casellas <ramon.casellas@cttc.es>, "fu.xihua@zte.com.cn" <
> fu.xihua@zte.com.cn>, Iftekhar Hussain <IHussain@infinera.com>
> *Cc:* Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, "
> Malcolm.BETTS@zte.com.cn" <Malcolm.BETTS@zte.com.cn>, Oscar González de
> Dios <ogondio@tid.es>, "Zhangxian (Xian)" <zhang.xian@huawei.com>, Fatai
> Zhang <zhangfatai@huawei.com>
> *Asunto:* *RE: slides for draft-ietf-ccamp-flexi-grid-fwk-01*
>
>    Hi Ramon,
>
>
>
> A GMPLS LSP per network media channel is indeed **not** the right approach.
>
>
>
> The GMPLS LSP has to represent the one optical channel layer connection
> that carries the complete OTUCn and thus encompasses all the associated
> network media channels; this GMPLS LSP is to be signaled with a list of
> frequency slots that are occupied by this optical channel layer connection.
> I.e. use an approach that is similar to the approach for signaling the set
> up of a multi-time slot ODUk connection.
>
> See also Xihua's email which was CC'ed to ccamp.
>
>
>
> As you already know how to signal a multi-time slot ODUk connection, you
> essentially know how to signal a multi-frequency slot optical channel layer
> connection. The main difference is that a frequency slot is defined by a
> <nominal center frequency and slot width>-tuple and not by a simple <slot
> number> as in the ODUk case.
>
>
>
> Regards,
>
> Maarten
>
>
>
> *From:* Ramon Casellas [mailto:ramon.casellas@cttc.es<ramon.casellas@cttc.es>]
>
> *Sent:* woensdag 5 maart 2014 08:29
> *To:* Maarten vissers; fu.xihua@zte.com.cn; Iftekhar Hussain
> *Cc:* Daniele Ceccarelli; Malcolm.BETTS@zte.com.cn; Oscar González de
> Dios; Zhangxian (Xian); Fatai Zhang
> *Subject:* Re: slides for draft-ietf-ccamp-flexi-grid-fwk-01
>
>
>
> El 05/03/2014 0:33, Maarten vissers escribió:
>
> Ramon,
>
>
>
> My suggestion is to focus on the optical channel layer connection and not
> on the media channel as described in my response to Xihua about an hour
> ago. An optical channel layer connection encompasses one or more network
> media channels. You have to configure optical channel layer cross connects
> in each NE in the computed path. An optical channel layer cross connect
> connects one or more frequency slots <FS1,FS2,..,FSn> between two or more
> ports.
>
>
>
> Awareness of network media channels is only required in the PCE, during
> optical channel layer path computation as described in my previous email.
>
>
> Hi again,
>
>
> In short, I want to understand whether, provided that the path computation
> function is able to compute a set of network media channels that are
> logically associated and that satisfy your constraints (i.e., compute the
> optical channel layer route), you think that having an LSP per network
> media channel where the label represents the frequency slot and associating
> them somehow (the method is still to be defined, channel sets, association,
> virtual concat, just to echo some terms) is *not* the right approach?
>
> R.
>
> Note: We should  CCccamp as requested in the past by AD & WG chairs to
> avoid parallel discussions.
>
>
> ------------------------------
>
> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
> nuestra política de envío y recepción de correo electrónico en el enlace
> situado más abajo.
> This message is intended exclusively for its addressee. We only send and
> receive email on the basis of the terms set out at:
> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
>
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp
>
>