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

<wang.qilei@zte.com.cn> Fri, 25 January 2019 01:02 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 0872E12D4E9 for <ccamp@ietfa.amsl.com>; Thu, 24 Jan 2019 17:02:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 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] 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 KFft9OBvEg5Y for <ccamp@ietfa.amsl.com>; Thu, 24 Jan 2019 17:02:54 -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 7714A128D09 for <ccamp@ietf.org>; Thu, 24 Jan 2019 17:02:52 -0800 (PST)
Received: from mxct.zte.com.cn (unknown [192.168.164.217]) by Forcepoint Email with ESMTPS id A7F6614DD70B4501D619 for <ccamp@ietf.org>; Fri, 25 Jan 2019 09:02:48 +0800 (CST)
Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Forcepoint Email with ESMTPS id 8FDBF5CC37986763C9BC; Fri, 25 Jan 2019 09:02:48 +0800 (CST)
Received: from kjyxapp03.zte.com.cn ([10.30.12.202]) by mse01.zte.com.cn with SMTP id x0P12iN1070121; Fri, 25 Jan 2019 09:02:44 +0800 (GMT-8) (envelope-from wang.qilei@zte.com.cn)
Received: from mapi (kjyxapp05[null]) by mapi (Zmail) with MAPI id mid16; Fri, 25 Jan 2019 09:02:45 +0800 (CST)
Date: Fri, 25 Jan 2019 09:02:45 +0800
X-Zmail-TransId: 2b075c4a6035baaacd1a
X-Mailer: Zmail v1.0
Message-ID: <201901250902450065431@zte.com.cn>
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 x0P12iN1070121
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/zVQoUj5JOaRauxq7r-FXikINVng>
Subject: Re: [CCAMP] Fwd: New Version Notificationfordraft-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: Fri, 25 Jan 2019 01:02:58 -0000

Hi Loa, 





Could you please give more explanation on why do you think  control plane is less useful for theFlexE Groups, while it is much more useful for FlexE Client?




If I remember correctly, I think recent discussion has already covered following case:

(1), MAC into FlexE client (we think FLEXE IA has already cover this.)

(2), FlexE client into FlexE Group (Presentation during IETF Bangkok meeting, we think FlexE IA also cover this too.)

(3), Create of FlexE group 

I would suggest we focus on these three points to figure out what new requirements are needed from control plane point of view.




With regard to your question, personally speaking, I would like to explain as the allocation of FlexE client according to the request could be dynamic, or it could be designated. In the latter case, only bandwidth requirement is feasible. Some detailed explanation below:

One FlexE client should use the same kind of ports (i.e., 10G, 40G.. they should be internal ports) at both source and destination node to ensure the correct encapsulation and recovery of the MAC frames. You just need to tell the source node the resource you want for this flow. The source node can decide which port it would like to use. When the signal arrives at the other side, the destination node could get this FlexE client information according to the overhead, and then it deliver the stream to physical port with the same pattern. No need to explicitly indicate the port chose, it's just a internal port.

In addition, I think one of the import feature that may need to taken into consideration is FlexE and FlexEC do not has routing capabilities. Routing of the information usually is done after the L3 packets (an example) are extracted out. Discssions are needed.






Thanks


Qilei







原始邮件



发件人:LoaAndersson <loa@pi.nu>
收件人:王其磊10101413;牛小兵10019881;
抄送人:ccamp@ietf.org <ccamp@ietf.org>;ccamp-chairs@tools.ietf.org <ccamp-chairs@tools.ietf.org>;
日 期 :2019年01月21日 12:14
主 题 :Re: [CCAMP] Fwd: New Version Notificationfordraft-izh-ccamp-flexe-fwk-06.txt


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