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

From: Dieter Beller <[email-masked]>
Date: Thu, 16 Nov 2017 02:41:11 +0100

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:

It is unclear what the intend for the semantics of the administrative 
locking function is. Is the intention that the group can be carrying 
live traffic when the group
is locked? The draft indicates that it is possible to add or remove PHYs 
from a group while the group is administratively locked. The FlexE IA 
says that PHYs cannot
be added or removed while the group is in service. Maybe the intent is 
that this would allow to temporarily ignore errors where the two ends 
temporarily think the
group is composed of a different set of PHYs and not bring the group 
down. But there is more to it than that: you need to deskew across a 
different set of PHYs,
which may mean adjusting the center point of the skew buffers to a 
different spot, which can’t be assured to be hitless bringing up a new 
group with a different
set of PHYs.

The biggest issue is with Figure 3 which illustrates FlexE client 
switching, which is not envisioned at all in the way 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.

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

---

From: Loa Andersson <[email-masked]>
Date: Thu, 16 Nov 2017 12:00:41 +0800

Dieter,

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

> plane issues I raised regarding draft-izh-ccamp-flexe-fwk-04:
tnx - much appreciated

> 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.

> have no kind of OAM that will allow you to find where faults or errors 

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

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Mach Chen <[email-masked]>
Date: Wed, 22 Nov 2017 02:42:06 +0000

Hi Dieter,

Thanks for your comments!

Please see my response inline...

> -----Original Message-----
> From: CCAMP [mailto:[email-masked]] On Behalf Of Dieter Beller
> Sent: Thursday, November 16, 2017 9:41 AM
> To: Loa Andersson <[email-masked]>
> Cc: [email-masked]
> Subject: [CCAMP] Comments on FlexE draft "draft-izh-ccamp-flexe-fwk-04"
> 
> 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:
> 
> It is unclear what the intend for the semantics of the administrative locking
> function is. Is the intention that the group can be carrying live traffic when the
> group is locked? The draft indicates that it is possible to add or remove PHYs
> from a group while the group is administratively locked. The FlexE IA says that

The administrative locking is to make sure the group is out of service and adding/removal PHYs can be done safely. 

> PHYs cannot be added or removed while the group is in service. Maybe the
> intent is that this would allow to temporarily ignore errors where the two ends
> temporarily think the group is composed of a different set of PHYs and not
> bring the group down. But there is more to it than that: you need to deskew
> across a different set of PHYs, which may mean adjusting the center point of
> the skew buffers to a different spot, which can’t be assured to be hitless
> bringing up a new group with a different set of PHYs.

It may work, but this is not defined in FlexE IA.

> 
> The biggest issue is with Figure 3 which illustrates FlexE client switching, which
> is not envisioned at all in the way FlexE is designed.

No, it's not the intention. 

Section 5.3 says:

"FlexE is a true link layer technology, i.e. it is not switched, this
   means that the FlexE Groups and FlexE Clients are terminated on the
   next-hop node, and that the switching needs to take place on a higher
   layer."

> 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.
> 
> 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.

Yes, this is the intention, if there are some places that you think are not the case, would like to discuss and update when needed.

Best regards,
Mach
> 
> 
> Thanks,
> Dieter
> 
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp