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

Loa Andersson <loa@pi.nu> Mon, 21 January 2019 04:14 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 1E91F12D84C for <ccamp@ietfa.amsl.com>; Sun, 20 Jan 2019 20:14:57 -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 xx2xU7nRQTWG for <ccamp@ietfa.amsl.com>; Sun, 20 Jan 2019 20:14:55 -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 1E26812D4E8 for <ccamp@ietf.org>; Sun, 20 Jan 2019 20:14:55 -0800 (PST)
Received: from [10.255.249.5] (unknown [176.126.84.122]) (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 1BDB2180158C; Mon, 21 Jan 2019 05:14:51 +0100 (CET)
To: wang.qilei@zte.com.cn, niu.xiaobing@zte.com.cn
Cc: ccamp@ietf.org, ccamp-chairs@tools.ietf.org
References: <201901201107461619529@zte.com.cn>
From: Loa Andersson <loa@pi.nu>
Message-ID: <2c864f1f-6f08-cc7b-33a3-7f9b78660147@pi.nu>
Date: Mon, 21 Jan 2019 12:14:48 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <201901201107461619529@zte.com.cn>
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/RF59XRrBzBThcTPq6DDvkgOp1NE>
Subject: Re: [CCAMP] Fwd: New Version Notification fordraft-izh-ccamp-flexe-fwk-06.txt
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: Mon, 21 Jan 2019 04:14:57 -0000

Qilei,

One more question in line.

On 2019-01-20 11:07, wang.qilei@zte.com.cn wrote:
> 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.

I would say the opposite - the control plane is less useful for the
FlexE Groups, while it is much more useful for FlexE Client.

On thought, if we have a control plane for FlexE Group, where is the
decision taken how may FlexE Clients you need for that FlexE Group?

/Loa
> 
> 
> 
> Thanks
> 
> Qilei
> 
> 
> 
> 
> 原始邮件
> *发件人:*LoaAndersson <loa@pi.nu>
> *收件人:*牛小兵10019881;
> *抄送人:*ccamp@ietf.org <ccamp@ietf.org>;ccamp-chairs@tools.ietf.org 
> <ccamp-chairs@tools.ietf.org>;
> *日 期 :*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>;
>  > *日 期 :*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>;
>  >  > *日 期 :*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
> 
> 

-- 


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