Re: [CCAMP] Fwd: New Version Notification fordraft-izh-ccamp-flexe-fwk-06.txt

<wang.qilei@zte.com.cn> Sun, 20 January 2019 03:07 UTC

Return-Path: <wang.qilei@zte.com.cn>
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 D32AA130F2A for <ccamp@ietfa.amsl.com>; Sat, 19 Jan 2019 19:07:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] 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 pd75ZmkUv94X for <ccamp@ietfa.amsl.com>; Sat, 19 Jan 2019 19:07:56 -0800 (PST)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4440E130F03 for <ccamp@ietf.org>; Sat, 19 Jan 2019 19:07:54 -0800 (PST)
Received: from mxct.zte.com.cn (unknown [192.168.164.217]) by Forcepoint Email with ESMTPS id 41DB68891AE9C83351EC for <ccamp@ietf.org>; Sun, 20 Jan 2019 11:07:51 +0800 (CST)
Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Forcepoint Email with ESMTPS id 2BF984438E3B500D81B6; Sun, 20 Jan 2019 11:07:51 +0800 (CST)
Received: from kjyxapp05.zte.com.cn ([10.30.12.204]) by mse01.zte.com.cn with SMTP id x0K37jVK046488; Sun, 20 Jan 2019 11:07:45 +0800 (GMT-8) (envelope-from wang.qilei@zte.com.cn)
Received: from mapi (kjyxapp07[null]) by mapi (Zmail) with MAPI id mid16; Sun, 20 Jan 2019 11:07:46 +0800 (CST)
Date: Sun, 20 Jan 2019 11:07:46 +0800 (CST)
X-Zmail-TransId: 2b095c43e6028e260189
X-Mailer: Zmail v1.0
Message-ID: <201901201107461619529@zte.com.cn>
In-Reply-To: <17445c64-75d6-8e69-eca0-77d5cd85c726@pi.nu>
References: 201901110807.x0B87Jlx085707@mse02.zte.com.cn, 17445c64-75d6-8e69-eca0-77d5cd85c726@pi.nu
Mime-Version: 1.0
From: <wang.qilei@zte.com.cn>
To: <loa@pi.nu>, <niu.xiaobing@zte.com.cn>
Cc: <ccamp@ietf.org>, <ccamp-chairs@tools.ietf.org>
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse01.zte.com.cn x0K37jVK046488
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/CyuK_o283QIEKXbAOgV3ohEWz3I>
Subject: Re: [CCAMP] =?utf-8?q?Fwd=3A_New_Version_Notification_fordraft-izh-c?= =?utf-8?q?camp-flexe-fwk-06=2Etxt?=
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 20 Jan 2019 03:07:59 -0000

Hi Loa,






I think the answer to your second question is yes.






If I understand Xiaobing correctly, I think he wanted to answer your question in another way. That is once a MAC frame is formed, the encapsulation of this MAC frame to FlexE client is in one single pipeline. Transcoding work is mainly included here, i.e., MAC frame --> 64/66bits. Choosing of FlexE client for different MAC frame is not needed. I copied the figure 82-1 of IEEE 802.3 below to describe this. MAC --> RS --> XLGMII/CGMII --> FlexE client.






In addition, I took a look at G.8023 published by ITU-T 11/15, and found some description we need to think about when updating the draft.


(1), clause 7, the FlexE model is not intended to imply that connection functions exist for the FlexE and FlexEC information.


(2), clause 8.1, As there is no overhead defined for monitoring a FlexE client, this is a null function (i.e., FlexE client trail termination function)






If I understand about this two sentences correctly, I think there is no need to use control plane method to configure FlexE client. For FlexE group, maybe what we need is just to create such a group. Discussions are needed.













Thanks


Qilei















原始邮件



发件人:LoaAndersson <loa@pi.nu>
收件人:牛小兵10019881;
抄送人:ccamp@ietf.org <ccamp@ietf.org>;ccamp-chairs@tools.ietf.org <ccamp-chairs@tools.ietf.org>rg>;
日 期 :2019年01月14日 15:34
主 题 :Re: [CCAMP] Fwd: New Version Notification fordraft-izh-ccamp-flexe-fwk-06.txt


Xiaobing,

The way I read you is that if I send an Ethernet frame over a FlexE
interface all the bits/bytes of this frame will be transmitted on the
same FlexE Client, right?

What I tried to ask repeatedly is that if I have e.g. three Ethernet
frames, and can identify frame 1 and 3 as belonging to the same flow,
while frame does not belong to that same flow, can I make sure that:

Frame 1 is transmitted over FlexE CLient-1
Frame 2 is not transmitted over FlexE Client-1
Frame 3 is transmitted over FlexE CLient-1

Is that possible????


/Loa

On 2019-01-11 14:11, niu.xiaobing@zte.com.cn wrote:
> hi,
> 
> Sorry for the late reply.
> 
>  From my understanding, when an Ethernet frame is to be transmitted over 
> Ethernet PHY (or FlexE group), it will be encapsultated and adapted 
> through RS and xMII into the FlexE client. It looks like a one-to-one 
> relationship between an Ethernet frame and the flexe client.
> 
> Refere to clause 5.2 'Relationship to IEEE 802.3 Stack' in FlexE 2.0 IA 
> for more information:
> 
> The FlexE Shim can be envisioned as being in the middle of the PCS in 
> the 100GBASE-R stack as illustrated in [802.3] Figure 80-1 or in the 
> 200GBASE-R or
> 
> 400GBASE-R stack as illustrated in [802.3bs] Figure 116-1. Each FlexE 
> Client has its own separate MAC, Reconciliation Sublayer, and xMII above 
> the FlexE Shim which
> 
> operate at the FlexE Client rate. The layers below the PCS (100GBASE-R 
> PMA, optional FEC, PMD) are used intact as specified for Ethernet.
> 
> 
> BRs,
> 
> 牛小兵     Xiaobing NIU
> 
> E: niu.xiaobing@zte.com.cn <mailto:niu.xiaobing@zte.com.cn>
> 
> www.zte.com.cn <http://www.zte.com.cn/>
> 
> 原始邮件
> *发件人:*LoaAndersson <loa@pi.nu>
> *收件人:*牛小兵10019881;
> *抄送人:*ccamp@ietf.org <ccamp@ietf.org>;ccamp-chairs@tools.ietf.org 
> <ccamp-chairs@tools.ietf.org>rg>;
> *日 期 :*2018年12月27日 14:28
> *主 题 :**Re:  [CCAMP] Fwd: New Version Notification 
> fordraft-izh-ccamp-flexe-fwk-06.txt*
> Xiaobing,
> 
> Let me see if I understand you correctly.
> 
> Let us assume that we have a 100GE PHY with on 100GE FlexE Group
> and that FlexE Group have 5 FlexE Clients.
> 
> If an Ethernet frame is to be transmitted over the FlexE Group, are you
> saying that it is arbitrary which FlexE Client it will be transmitted
> over??
> 
> /Loa
> 
> 
> On 2018-12-25 14:41, niu.xiaobing@zte.com.cn wrote:
>  > hi Loa,
>  >
>  > Sorry for the late reply.
>  >
>  > In Fig2, 3,  and  4 of FlexE 2.0 IA, 'control' model works in this way,
>  >
>  > The control function manages which calendar slots each FlexE Client is
>  > inserted into
>  >
>  > and inserts the FlexE overhead on each FlexE PHY in the transmit direction.
>  >
>  > It does not relate to the mapping from 'the correct
>  > Ethernet Frame to the correct FlexE Client' in the FlexE Mux.
>  >
>  > I'm not sure if I understand your question correctly.
>  >
>  >
>  > Happy Christmas!
>  >
>  >
>  > 牛小兵     Xiaobing NIU
>  >
>  > 标准预研工程师   Standard Engineer
>  >
>  > 算法标准部/有线研究院/有线产品经营部   Algorithm Standard Department/
>  > Wireline Product R&D Institute
>  >
>  > **
>  >
>  > 中兴通讯股份有限公司   ZTE Corporation
>  >
>  > 北京市朝阳区安定路5号院8号外运大厦A座4楼, 邮编: 100029
>  >
>  > 4/F, Sinotrans Tower A, Building 8, No.5 Anding Road, Chaoyang
>  > District,Beijing, P.R.China,
>  >
>  > T: +86 755 xxxxxxxx M: +86 13439566425 <javascript:void(0);>
>  >
>  > E: niu.xiaobing@zte.com.cn <mailto:niu.xiaobing@zte.com.cn>
>  >
>  > www.zte.com.cn <http://www.zte.com.cn/>
>  >
>  >
>  > *发件人:*LoaAndersson <loa@pi.nu>
>  > *收件人:*牛小兵10019881;
>  > *抄送人:*ccamp@ietf.org <ccamp@ietf.org>;ccamp-chairs@tools.ietf.org
>  > <ccamp-chairs@tools.ietf.org>rg>;
>  > *日 期 :*2018年12月19日 14:37
>  > *主 题 :**Re:  [CCAMP] Fwd: New Version Notification
>  > fordraft-izh-ccamp-flexe-fwk-06.txt*
>  >
>  >
>  > On 2018-12-18 17:52, niu.xiaobing@zte.com.cn wrote:
>  >  > hi, Loa
>  >
>  > <snip>
>  >  >
>  >  > Once a FlexE group is created, it can be seen as one huge PCS module
>  >  > created as well. Transport of different FlexE client information streams
>  >  > over the FlexE group is decided by the data plane "control" module.
>  >
>  > What info does the data plane "control" module use to map the correct
>  > Ethernet Frame to the correct FlexE Client?
>  >
>  > /Loa
>  >
>  > <nip>
>  >
>  >
>  >
>  > --
>  >
>  >
>  > Loa Andersson                        email: loa@pi.nu
>  > Senior MPLS Expert
>  > Bronze Dragon Consulting             phone: +46 739 81 21 64
>  >
>  >
> 
> -- 
> 
> 
> Loa Andersson                        email: loa@pi.nu
> Senior MPLS Expert
> Bronze Dragon Consulting             phone: +46 739 81 21 64
> 
> 

-- 


Loa Andersson                        email: loa@pi.nu
Senior MPLS Expert
Bronze Dragon Consulting             phone: +46 739 81 21 64

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