Liaison statement
LS/r on Flex Ethernet for IP/MPLS Networks (reply to IETF ccamp WG-LS15 (26 May 2017), posted as TD38/WP3)

Thank you for informing SG15 about individual contributions into IETF CCAMP
related FlexE. For the ITU-T Study Period 2017-2020, SG15 is studying transport
of FlexE over OTN. G.709 (2016) clause 7 and G.872 (2017) describe the use of
OTN to carry FlexE. However, no modification of FlexE from the OIF “Flex
Ethernet Implementation Agreement” (IA OIF-FLEXE-01.0) is in SG15’s current
work programme. It is only being defined in the OIF, not currently in the ITU-T.

Note that FlexE is presently a link technology and that a MAC client cannot
distinguish whether it is being adapted onto an Ethernet PHY or a FlexE. That
is, it is a server layer to the MAC client whose details are not visible nor
controllable by, the MAC client. As stated in the section 5.2 of the
OIF-FLEXE-01.0 IA:

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

Since the MAC client cannot distinguish whether it is being mapped into an ETH
PHY or a FlexE, the implications of the FlexE shim being below the IEEE 802.3
Reconciliation Sublayer are: - A FlexE calendar slot is not visible to the MAC
client. It cannot be specified in the client adaptation to the FlexE link.
There is no awareness of the calendar slot when the MAC frame is recovered at
the egress of a FlexE link. - There is no mechanism to isolate traffic within
FlexE to associate an MPLS label with a calendar slot. - Allocation of calendar
slots to a network slicing instance is not possible as the 66B block
distribution is not influenced by any information in the FlexE client.

Note that the 66B blocks from the FlexE calendar are not switched. Information
transfer between the egress of a FlexE link and the ingress of another FlexE
link is only presently possible via the MAC layer. Control plane protocols that
can use existing Ethernet links should be able to accommodate FlexE links
through modifications to the bitrate value associated with the link and would
not need to distinguish them as being different from any other Ethernet link.

We hope this description is helpful to CCAMP, and encourage direct interaction
with the OIF should modifications to FlexE be considered. Please keep SG15
informed as your work progresses.