Re: [CCAMP] Comments on FlexE draft "draft-izh-ccamp-flexe-fwk-04"

Loa Andersson <loa@pi.nu> Thu, 16 November 2017 04:00 UTC

Return-Path: <loa@pi.nu>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE6B312948E for <ccamp@ietfa.amsl.com>; Wed, 15 Nov 2017 20:00:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=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 5IXnToeIPRSN for <ccamp@ietfa.amsl.com>; Wed, 15 Nov 2017 20:00:48 -0800 (PST)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F17C124BE8 for <ccamp@ietf.org>; Wed, 15 Nov 2017 20:00:48 -0800 (PST)
Received: from [31.133.131.150] (dhcp-8396.meeting.ietf.org [31.133.131.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id DD9E418008CB; Thu, 16 Nov 2017 05:00:45 +0100 (CET)
To: Dieter Beller <Dieter.Beller@nokia.com>
Cc: "ccamp@ietf.org" <ccamp@ietf.org>
References: <9152691e-8f19-b8a5-2d44-34e923541da3@nokia.com>
From: Loa Andersson <loa@pi.nu>
Message-ID: <7cb2d691-3c2a-d314-64b7-84ff45595981@pi.nu>
Date: Thu, 16 Nov 2017 12:00:41 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <9152691e-8f19-b8a5-2d44-34e923541da3@nokia.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/Wg1H7g2sFWv0WVhkovV3tzQvKxA>
Subject: Re: [CCAMP] Comments on FlexE draft "draft-izh-ccamp-flexe-fwk-04"
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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, 16 Nov 2017 04:00:50 -0000

Dieter,

Response to the comment on figure 3, the comment on locked state, I will
need to come with an ansswer to.

On 2017-11-16 09:41, Dieter Beller wrote:
> Hi Loa,
> 
> please find as promised during the CCAMP session the two FlexE data 
> plane issues I raised regarding draft-izh-ccamp-flexe-fwk-04:
> 
tnx - much appreciated

> 
> The biggest issue is with Figure 3 which illustrates FlexE client 
> switching,
no it does not! What is illustrated is th mapping of an LSP over a
FlexE Client and FlexE Group, the LSP is switched the FlexE Client
and FlexE Group are terminated in each node.

the "x" in the middle node indicates where switching is done, i.e. on
the LSP level.

  which is not envisioned at all in the way FlexE is designed.

if the figure did describe FlexE Switching I would agree, but
since it is not, I think we are well aligned with how FLexE is
designed.

> What you can do is to have a
> FlexE group at the transport network ingress and another FlexE group at 
> the transport network egress, mapping the FlexE client into an ODUflex 
> which is
> switched as an LSP from one end to the other. But what they are 
> illustrating is a set of network nodes that are interconnected by FlexE 
> groups and daisy-chaining
> this together to create a path through the network. The difficulty is 
> that a FlexE client has been designed to have the semantics of an 
> Ethernet PHY, which is a link
> rather than a layer network. The nodes they are illustrating would have 
> the semantics of a kind of crossbar switch interconnecting Ethernet PHYs 
> in cut-through
> mode. This has a bunch of issues: you are carrying the 66B flow over 
> multiple link segments without going through any Ethernet bridge that 
> would discard MAC
> frames with bad MAC FCS and the MTTFPA can’t be maintained, and you also 
> have no kind of OAM that will allow you to find where faults or errors 
> occurred in the
> network.

If I read the OIF IA correctly, the FlexE Group corresponds to the 
Ethernet PHY and FLexE CLient corresponds to the Ethernet MAC.

 From the IA:
The FlexE Group refers to a group of from 1 to n bonded Ethernet PHYs.
This version of the Implementation Agreement supports FlexE groups
composed of one or more bonded 100GBASE-R PHYs. New higher rates (e.g.,
400GbE under development in the IEEE P802.3bs project) are intended to
be included once those standards are complete.

A FlexE Client is an Ethernet flow based on a MAC data rate that may or
may not correspond to any Ethernet PHY rate. The FlexE client MAC rates
supported by this implementation agreement are 10, 40, and m × 25 Gb/s.

/Loa
> 
> The draft must not add any FlexE data plane functionality and the FlexE 
> draft should strictly be scoped to GMPLS control plane aspects for a 
> given data plane.
> 
> 
> Thanks,
> Dieter
> 

-- 


Loa Andersson                        email: loa@pi.nu
Senior MPLS Expert
Huawei Technologies (consultant)     phone: +46 739 81 21 64