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

[Loa Andersson <[e-mail]>]

Qilei,

When I said "opposite" I didn't really mean to compare the usefulness
of control plane established FlexE Group vs. FlexE Clients. Rather I
intended to say that I think that the capability to establish FlexE
Clients would be rather handy. After all I could imagine that the
dynamics on the FlexE Client level is higher than at the FlexE Group
level.

I also notice that you avoided to respond to my real question.

"...if we have a control plane for FlexE Group, where is the
  decision taken how many FlexE Clients you need for that FlexE Group?"

/Loa


On 2019-01-25 09:02, [e-mail] wrote:
> Hi Loa,
> 
> 
> Could you please give more explanation on why do you 
> think  control plane is less useful for the FlexE 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 <[e-mail]>
> *收件人：*王其磊10101413;牛小兵10019881;
> *抄送人：*[e-mail] <[e-mail]>;[e-mail] 
> <[e-mail]>;
> *日 期 ：*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, [e-mail] 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 <[e-mail]>
>  > *收件人：*牛小兵10019881;
>  > *抄送人：*[e-mail] <[e-mail]>;[e-mail]
>  > <[e-mail]>;
>  > *日 期 ：*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, [e-mail] 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: [e-mail] <mailto:[e-mail]>
>  >  >
>  >  > www.zte.com.cn <http://www.zte.com.cn/>
>  >  >
>  >  > 原始邮件
>  >  > *发件人：*LoaAndersson <loa@pi..nu>
>  >  > *收件人：*牛小兵10019881;
>  >  > *抄送人：*[e-mail] <[e-mail]>;[e-mail]
>  >  > <[e-mail]>;
>  >  > *日 期 ：*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, [e-mail] 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: [phone] <javascript:void(0);>
>  >  >  >
>  >  >  > E: [e-mail] <mailto:[e-mail]>
>  >  >  >
>  >  >  > www.zte.com.cn <http://www.zte.com.cn/>
>  >  >  >
>  >  >  >
>  >  >  > *发件人：*LoaAndersson <[e-mail]>
>  >  >  > *收件人：*牛小兵10019881;
>  >  >  > *抄送人：*[e-mail] <[e-mail]>;ccamp- 
> [e-mail]
>  >  >  > <[e-mail]>;
>  >  >  > *日 期 ：*2018年12月19日 14:37
>  >  >  > *主 题 ：**Re:  [CCAMP] Fwd: New Version Notification
>  >  >  > fordraft-izh-ccamp-flexe-fwk-06.txt*
>  >  >  >
>  >  >  >
>  >  >  > On 2018-12-18 17:52, [e-mail] 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: [e-mail]
>  >  >  > Senior MPLS Expert
>  >  >  > Bronze Dragon Consulting             phone: [phone]
>  >  >  >
>  >  >  >
>  >  >
>  >  > --
>  >  >
>  >  >
>  >  > Loa Andersson                        email: [e-mail]
>  >  > Senior MPLS Expert
>  >  > Bronze Dragon Consulting             phone: [phone]
>  >  >
>  >  >
>  >
>  > --
>  >
>  >
>  > Loa Andersson                        email: [e-mail]
>  > Senior MPLS Expert
>  > Bronze Dragon Consulting             phone: [phone]
>  >
>  > _______________________________________________
>  > CCAMP mailing list
>  > [e-mail]
>  > https://www.ietf.org/mailman/listinfo/ccamp
>  >
>  >
> 
> -- 
> 
> 
> Loa Andersson                        email: [e-mail]
> Senior MPLS Expert
> Bronze Dragon Consulting             phone: [phone]
> 
> 

-- 


Loa Andersson                        email: [e-mail]
Senior MPLS Expert
Bronze Dragon Consulting             phone: [phone]