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

[Liaison Statement Management Tool <[e-mail]>]

Title: LS/r on Flex Ethernet for IP/MPLS Networks (reply to IETF ccamp WG-LS15 (26 May 2017), posted as TD38/WP3)
Submission Date: 2017-07-06
URL of the IETF Web page: https://datatracker.ietf.org/liaison/1535/

From: Hiroshi Ota <[e-mail]>
To: Daniele Ceccarelli <[e-mail]>,Fatai Zhang <[e-mail]>
Cc: Alvaro Retana <[e-mail]>,Deborah Brungard <[e-mail]>,Scott Mansfield <[e-mail]>,Fatai Zhang <[e-mail]>,John Drake <[e-mail]>,Alia Atlas <[e-mail]>,Daniele Ceccarelli <[e-mail]>,Common Control and Measurement Plane Discussion List <[e-mail]>,[e-mail]
Response Contacts: [e-mail], [e-mail]
Technical Contacts: 
Purpose: For information

Body: 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.
Attachments:

    SG15-LS45
    https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2017-07-06-itu-t-sg-15-ccamp-lsr-on-flex-ethernet-for-ipmpls-networks-reply-to-ietf-ccamp-wg-ls15-26-may-2017-posted-as-td38wp3-attachment-1.pdf