[netmod] Fwd: [CCAMP] Comments on draft-sambo-ccamp-yang-fsm-transponder-reconf-00

nicola sambo <nicosambo@gmail.com> Thu, 22 March 2018 12:21 UTC

Return-Path: <nicosambo@gmail.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D958A1242F7 for <netmod@ietfa.amsl.com>; Thu, 22 Mar 2018 05:21:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 D75FVRK7cFc4 for <netmod@ietfa.amsl.com>; Thu, 22 Mar 2018 05:21:36 -0700 (PDT)
Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 577491200C5 for <netmod@ietf.org>; Thu, 22 Mar 2018 05:21:36 -0700 (PDT)
Received: by mail-pg0-x22c.google.com with SMTP id i9so3165718pgq.10 for <netmod@ietf.org>; Thu, 22 Mar 2018 05:21:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=SfEK7LnWmvHX5XXKtKmRxB9NmyjSo9unBscVIBxdZ7Y=; b=NuAzyBZXi9c9bjvrFJyo7Sjy9++OdDhXEgzYcChmlB6jCYjxS4DpFJv67HGY6IcEjV jfwp7zkMM3wmxMFEClzjAawX/7hS+938BfDgCQlny9yCBibxCuU7wpgmzyud+zzzESFz ZgqinU9KUXlXnaNQI0xfhLMd7JmvAjTiv+gVMPu8porVBWIhoLdiz+A/NgtkWrVTdC9S g5bX0Qm8eCL9LgDKsC+DYljVmrvxYmIx7AeaxUgJFz0/Q9/P9+/iOD3aouSNHr3QANt9 xjhJF6xR+Vn4LeCY2NJB7Ej876/L8WiTh+mFbm8vQebaVZ/fw3D82uEPOtldmE1xA80C RZFQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=SfEK7LnWmvHX5XXKtKmRxB9NmyjSo9unBscVIBxdZ7Y=; b=pth8FBS17QcdYZAIOAIgFKkf1Id4u4oiiFMEmWUi68wT5PZpVUBaZu/ex3ZlBi84/a DsQ6WK3dP+Yh5c0cw5XIVGaaeyp7aMiv1gq/G6gDVJAlTj/+13jtjRY+UwtdCs32eI3b rNN3wfu3AyPrcO1ZyW+rXbGSEMJgapswY6Xn6fVh92MYF1lJaGfFjfyvTFdRuyG3UJMV BZYYfikVDOGDEs9aP/0tyBhiH/vlkM1xsu0dAChUPTGhm0E4RF08YWe2UQ6gTTieB8TJ Mv44MgaKiObi5xLPa+Hzg0nN3PoRnUUclntGy1Euu/EC8zimNgGEirlPty7lkJ0RpOEu URkA==
X-Gm-Message-State: AElRT7EN2hiiImU/gbuvm9+fSS9gYXIKJ8AsdO+uMS1u88Cly586Xdhh QGE9Vg981MR3Rnkyry/iWrgJYa89zMaoZyp7pyk=
X-Google-Smtp-Source: AG47ELtkUBWldxC/3ugZ8FNuolZM+MPkKjECaAATFXBsWkh3VV2NnO8R80r3i759Rwuk6pMstlXWIyC0IL5N2+u30tM=
X-Received: by 10.99.97.149 with SMTP id v143mr17797759pgb.319.1521721295383; Thu, 22 Mar 2018 05:21:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.236.161.8 with HTTP; Thu, 22 Mar 2018 05:21:34 -0700 (PDT)
In-Reply-To: <CADqwGbecQN55r5+KrJwppYO4H1eokuCSQgWA7i-Av_-zo_8wTQ@mail.gmail.com>
References: <2e8e5191-77cd-6576-890e-45a7d8c007d7@nokia.com> <CADqwGbecQN55r5+KrJwppYO4H1eokuCSQgWA7i-Av_-zo_8wTQ@mail.gmail.com>
From: nicola sambo <nicosambo@gmail.com>
Date: Thu, 22 Mar 2018 13:21:34 +0100
Message-ID: <CADqwGbcJcrWRAoCUeSY0kR=-tm9zXvhTx=18dgR5O6nrqq1fng@mail.gmail.com>
To: netmod@ietf.org, n.sambo@sssup.it
Content-Type: multipart/alternative; boundary="94eb2c0cc38242333a0567ff59d2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/LVnfzLKz0JDImJXUolp_er5TI50>
Subject: [netmod] Fwd: [CCAMP] Comments on draft-sambo-ccamp-yang-fsm-transponder-reconf-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Mar 2018 12:21:39 -0000

Hi all,

I forward this email exchange from ccamp since can be of interest within
netmod in relation with the generic FSM model.

Best,
Nicola


---------- Messaggio inoltrato ----------
Da: *nicola sambo* <nicosambo@gmail.com>
Data: giovedì 22 marzo 2018
Oggetto: [CCAMP] Comments on
draft-sambo-ccamp-yang-fsm-transponder-reconf-00
A: Dieter Beller <Dieter.Beller@nokia.com>
Cc: nicola.sambo@sssup.it, "ccamp@ietf.org" <ccamp@ietf.org>


Hi Dieter,

answers inline:

2018-03-21 19:54 GMT+01:00 Dieter Beller <Dieter.Beller@nokia.com>:

> Hi Nicola,
>
> as there was no time left for providing my comments at the end of the
> CCAMP session this morning, I am providing my comments by e-mail:
>
> Are you assuming that the FSM is running autonomously on the optical
> transponder? What are the events that  trigger state transitions?
>

the FSM is installed by the SDN controller in the agent of the transponder
and then runs there. We enabled this instruction with a NETCONF
<edit-config> message.

For the case of a transponder, the events can be a BER above the threshold
or the OSNR below a threshold or some other monitored parameter. We assumed
these parameters monitored at the DSP of coherent receiver.


> I understood that there are local events that the optical transponder
> creates and there can also be external events coming from an SDN controller
> for example.
>

The events are detected (more than created) by the transponder at the
receiver end. The SDN controller only instructs the transponder about the
possible events and reactions by setting the thresholds and the
reconfiguration settings. So, the SDN controller only instructs the
transponder.



>
> Slide 6 only shows half of the picture: when the FSM of an OT decides to
> change its state, the remote transponder has to do exactly the same state
> transition.
> If the two transponders terminating the optical signal are not configured
> consistently, no traffic can be carried across the optical path. This means
> that state
> changes require coordination between the two optical transponders. How is
> this accomplished such that the service disruption time is minimized?
>

One of the actions when the event is detected is this coordination. The
transponder at the receiver side sends a message to the  transmitter to
synchronize about the transmission parameters to be adopted. This message
can be sent over a control channel. This way both the tx and rx know the
format, FEC, and so on.

We mentioned this in the draft. We will add a more detailed paragraph in
the new version of the draft.



>
> Slide 6 shows an example where the modulation scheme is changed from
> 16-QAM to QPSK. This reduces the data rate of the traffic to 50% (from
> 200Gbps
> to 100Gbps for example). I suppose that the traffic that can be dropped
> must be best effort traffic.
>

Yes, right. We can also expand this in the new version, by referring to
service classes use cases from Telecom Italia and DT.



>
> These network operations issues need to be addressed in the draft for this
> specific optical transponder FSM use case. Otherwise, its applicability is
> doubtful.
>
>
Ok. We'll clarify these points in the version 01.

Thanks.

Best,
Nicola



>
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp
>