Internet DRAFT - draft-jiang-ccamp-flexe-ifmps

draft-jiang-ccamp-flexe-ifmps



Network Working Group                                 Y. Jiang
Internet Draft                                         F. Yang
Intended status: Informational                         I. Busi
                                                        Huawei
                                                       J. Wang
                                                     Fiberhome
Expires: May 2020                         November 4, 2019


            Problem Statements of FlexE Interface Management
                   draft-jiang-ccamp-flexe-ifmps-00


Abstract

   This document outlines the problem statements for FlexE interface
   management; it also gives an analysis of configuration requirements
   for Flex Ethernet (FlexE) interface management. Requirements on FlexE
   interface management are summarized in the end.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF). Note that other groups may also distribute working
   documents as Internet-Drafts. The list of current Internet-Drafts is
   at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 4, 2020.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of




Jiang, et al                Expires May 4, 2020          [Page 1]

Internet-Draft               FlexE Management PS      November 2019


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.    Introduction ........................................ 2
      1.1.  Conventions used in this document ................ 3
      1.2.  Terminology ...................................... 4
   2.    Problem statements .................................. 4
      2.1.  Overview of FlexE management ..................... 4
      2.2.  Considerations on parameters in FlexE Overhead ... 5
      2.2.1. Static or configurable .......................... 6
      2.2.2. Negotiation enable or not ....................... 7
      2.2.3. Management of FlexE clients ..................... 7
      2.3.  Considerations on bidirectional transport ........ 8
   3.    Requirements ........................................ 9
   4.    Security Considerations ............................ 10
   5.    IANA Considerations ................................ 10
   6.    References ......................................... 10
      6.1.  Normative References ............................ 10
      6.2.  Informative References .......................... 10
   7.    Acknowledgments .................................... 10



1. Introduction

   The Flex Ethernet (FlexE) 2.0 Implementation Agreement
   [FLEXE] defined by the OIF provides the support of a
   variety of Ethernet MAC rates that may or may not
   correspond to any existing Ethernet PHY rate. This
   includes MAC rates that are both greater than (through
   bonding) and less than (through sub-rate and
   channelization) the Ethernet PHY rates used to carry
   FlexE.

   Besides 100GBASE-R PHYs as supported in FlexE 1.0, FlexE
   2.0 supports the bonding of 200GBASE-R PHYs or 400GBASE-R
   PHYs respectively. FlexE 2.1 further supports the bonding
   of 50GBASE-R PHYs.

   According to [FLEXE], FlexE supports the following
   features:

   - Bonding of multiple ETH PHYs (1~254)




Jiang, et al                Expires May 4, 2020          [Page 2]

Internet-Draft               FlexE Management PS      November 2019


   - Sub-rates of ETH PHY (minimum of 5G to maximum capacity
   of bandwidth in a PHY)

   - Channelization within a PHY or a group of bonded PHYs
   (5G ~ k*5G, combination of multiple slots, where each
   slot can be allocated from any PHY)

   In the FlexE, multiple Ethernet PHYs (each PHY can
   further consist of one or more FlexE Instances) are
   bonded into a FlexE Group, and the total capacity of the
   FlexE Group is represented as a collection of slots (e.g.,
   each slot has a granularity of 5Gbps or 25Gbps).  Based
   on their bandwidth needs, FlexE Clients are each
   allocated with one or more slots in a FlexE group. The
   FlexE mechanism operates by using a calendar consisting
   of these slots.

   This calendar is partitioned into sub-calendars for each
   PHY (earlier than FlexE 2.0) or sub-calendars for each
   FlexE instance (FlexE 2.0 and above). For example, the
   calendar for a FlexE Group composed of n 100G PHYs is
   partitioned into 20n slots (each slot representing 5Gbps
   of bandwidth when the slot granularity is 5Gbps).

   Some FlexE use cases are introduced in details in [flexe-
   usecases].

   This document describes the problem statements for FlexE
   interface management to support the transport of FlexE
   clients over a FlexE Group between two FlexE nodes. The
   equipment can be routers or optical transport products,
   which can support FlexE interfaces. Multiple hops of
   FlexE aware transport in OTN or MTN is out of the scope
   of this document.

1.1. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
   "SHALL      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
   "NOT RECOMMENDED",      "MAY", and "OPTIONAL" in this
   document are to be interpreted as      described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they
   appear in all capitals, as shown here.






Jiang, et al                Expires May 4, 2020          [Page 3]

Internet-Draft               FlexE Management PS      November 2019


1.2. Terminology

   Terminologies used in this document are extracted from
   [FLEXE].

   FlexE: Flex Ethernet.

   FlexE Client: An Ethernet flow based on a MAC data rate
   that may or may not correspond to any Ethernet PHY rate,
   the format of the FlexE Client is simply a logically
   serial stream of 66B blocks at a given rate.

   FlexE Group: A FlexE Group is composed of from 1 to n
   Ethernet PHYs.

   FlexE Instance: A FlexE Instance is a unit of information
   consisting of 100G of capacity able to carry FlexE Client
   data, together with its associated overhead.

   Ethernet PHY: an entity representing Ethernet Physical
   Coding Sublayer (PCS), Physical Media Attachment (PMA),
   and Physical Media Dependent (PMD) layers. Each PHY is
   consisted of one or more FlexE Instance (e.g., a
   400GBASE-R PHY has four FlexE Instances).

   FlexE Calendar: The total capacity of a FlexE Group is
   represented as a collection of slots.  The calendar for a
   FlexE Group composed of n PHYs is represented in each PHY
   as an array of slots (e.g., each representing 5Gbps of
   bandwidth), i.e., calendar-slot-list.

   CCA: Calendar Configuration A

   CCB: Calendar Configuration B

2. Problem statements

2.1. Overview of FlexE management

   Figure 1 depicts the overview diagram of FlexE management
   for a FlexE Group between PE1 and PE2, where PE1 and PE2
   are network equipments such as routers or OTN products.
   SDN/NMS may control or manage the FlexE Group between PE1
   and PE2 by interactions with PE1 and PE2 separately (by
   using Netconf or Restconf to connect with a management or
   control agent on each PE node).



Jiang, et al                Expires May 4, 2020          [Page 4]

Internet-Draft               FlexE Management PS      November 2019









                          +-----------+
                          |           |
                          | SDN/NMS   |
                          |           |
                          +-----------+
                           //      \\
                         //          \
                       //             \\
                     //                 \
                   //                    \\
      +-----------*  FlexE Group           *-----------+
      |           |     --           PHY1  |           |
      |  PE1      +----/--\----------------+  PE2      |
      |           |   |    |         PHY2  |           |
      |           +---+----+---------------+           |
      |           |   |    |         PHYn  |           |
      |           +---+----+---------------+           |
      |           |    \  /                |           |
      |           |     --                 |           |
      |           |                        |           |
      +-----------+                        +-----------+

                Figure 1: FlexE management overview

2.2. Considerations on parameters in FlexE Overhead

   The OIF specifies how the configuration and verification
   of a FlexE Group can be realized in Section 7.3 of
   [FLEXE]. A FlexE Overhead Frame is defined in [FLEXE] to
   convey FlexE group specific information from PE1 to PE2,
   including configuration information (FlexE Group Number,
   FlexE Map, FlexE PHY/Instance Number, CCA and CCB),
   status information (RPF) and signaling information (CC,
   CR and CA).

   The configuration information in the overhead frame is
   used by the receiving side to verify that both ends are
   properly configured with the same set of values in a
   FlexE Group. If PE2 finds out that the configuration



Jiang, et al                Expires May 4, 2020          [Page 5]

Internet-Draft               FlexE Management PS      November 2019


   information in the overhead sent from PE1 does not match
   its own configuration, a mismatch alarm should be raised.

   Note: Two calendar configurations are used in the FlexE
   data plane to facilitate reconfiguration, i.e., CCA and
   CCB. They are actually two lists (e.g., each list is
   20*2Bytes for a PHY of 100GBASE-R; or 4*20*2Bytes for a
   PHY of 400GBASE-R) wherein each list item indicates the
   client number carried in a calendar slot. At any given
   time, only one of the calendar configurations is active
   and used for mapping the FlexE Clients into the FlexE
   Group and demapping the FlexE Clients from the FlexE
   Group. When a switch of calendar configurations
   adds/removes/resizes FlexE Clients in a FlexE Group, the
   switching does not affect existing clients whose size and
   calendar slot assignments are not changed.

   Status information indicates status of the bonded PHYs,
   currently only RPF (Remote PHY Fault) is defined in
   [FLEXE], which informs the far-end of a locally detected
   failure of the PHY if set to one.

   The signaling information can be used to coordinate the
   switching from the active calendar configuration (e.g.,
   CCA) to the backup calendar configuration (e.g., CCB)
   between PE1 and PE2. As described in 7.3.4 of [FLEXE], CC,
   CR and CA are used to coordinate the switching of
   calendar A to calendar B or vice versa between the FlexE
   mux and FlexE demux (i.e., the source and the sink of a
   FlexE group).  The protocol is optional to implement.

2.2.1.  Static or configurable

   If the FlexE is static, a FlexE Group is composed of a
   fixed number of FlexE PHYs, e.g., simple bonding for a
   single fixed client; fixed calendar configuration. That
   means, there is no need to configure a device or it is
   impossible to configure the device. Some simple
   implementations only support static configuration.

   If the FlexE is configurable, the FlexE parameters can be
   controlled by a SDN controller or be configured by a
   network management system (NMS).

   A FlexE static PE usually interconnect with another PE in
   FlexE static (it is required that both PEs implement a
   FlexE group with exact the same set of fixed parameter


Jiang, et al                Expires May 4, 2020          [Page 6]

Internet-Draft               FlexE Management PS      November 2019


   values). However, sometimes there is a need to
   interconnect one FlexE static PE with another PE in FlexE
   configurable if the latter is properly configured with
   the same set of fixed parameter values.

2.2.2.  Negotiation enable or not

   [FLEXE] uses two calendar configurations (i.e., CCA and
   CCB) to facilitate client reconfiguration. Furthermore,
   Section 7.3 of [FLEXE] specifies a dynamic negotiation
   protocol (by signaling in the FlexE overhead) for the
   automatic switching of calendars in a FlexE Group. If
   this negotiation protocol is enabled (if one PE enables
   negotiation, the other PE MUST enable negotiation too), a
   receiving PE (i.e., slave) can further extract the
   configuration information (particularly CCA and CCB) from
   the FlexE overhead and multi-frame sent from a sending PE
   (i.e., master).

   It seems that the slave does not need to configure any
   FlexE parameters if negotiation protocol is enabled.
   However, from the viewpoint of bidirectional transport, a
   receiving PE in one direction is also acting as a sending
   PE in the other direction. Furthermore, FlexE group and
   its bonding PHYs must be configured firstly so that FlexE
   overhead channel can be set up for the signaling protocol
   to work properly. Therefore, FlexE configuration is
   needed on both side of PEs even if negotiation is enabled.

   Since the dynamic signaling of CC, CR and CA is done
   automatically in the data plane (especially, CR and CA
   are request and acknowledgement exchanged dynamically
   over the FlexE overhead, CC decides whether CCA or CCB is
   active), the mechanism works on the FlexE data plane
   independent from the management plane. Exposing all these
   signaling information to the management plane is not only
   unnecessary, but also greatly complicates the operations
   of FlexE. Thus, it is not needed to configure or retrieve
   these ephemeral signaling states.

2.2.3.  Management of FlexE clients

   The following management of FlexE clients needs to be
   supported:

   -Add a client or clients



Jiang, et al                Expires May 4, 2020          [Page 7]

Internet-Draft               FlexE Management PS      November 2019


   -Delete a client or clients

   -resize a client or clients

   -adjust slot locations for a client or clients

   If the negotiation protocol is not enabled, management of
   FlexE clients (add/delete/resize/adjust) usually is a
   sequential action to the current calendar of each FlexE
   PE, and retrieval of the calendar configuration values is
   also based on the active calendar. Thus, synchronous
   switching from the active calendar configuration to the
   backup calendar configuration is not needed. However,
   some client traffic may be lost during the
   reconfiguration.

   If the negotiation protocol is enabled, management of
   FlexE clients (add/delete/resize/adjust) usually is a
   sequential action to the backup calendar of each FlexE PE.
   Then dynamic negotiation as described in Section 2.2.2
   controls peer PEs to switch the backup calendar
   configuration into the active calendar configuration
   synchronously. The switching is hitless since the client
   traffic is not lost during the reconfiguration, thus it
   is recommended to be the default working mode. Moreover,
   retrieval of the calendar configuration values SHOULD be
   based on the new active calendar after protocol
   convergence (the convergence time is expected to be
   around 10ms calculated according to [FLEXE]).

   In either cases, the management plane only needs to deal
   with a single calendar, and there is no need to monitor
   whether the calendar is CCA or CCB from the SDN/NMS point
   of view.



2.3. Considerations on bidirectional transport

   OIF only discusses the configuration of a unidirectional
   client.

   In fact, the overhead signaling of CR and CA relies on a
   bidirectional channel in the same FlexE Group.

   Furthermore, the FlexE links (including each of the
   bonding PHYs) are always bidirectional, and FlexE clients


Jiang, et al                Expires May 4, 2020          [Page 8]

Internet-Draft               FlexE Management PS      November 2019


   are usually reserved with the same number of slots (or
   bandwidth) in both directions over the same FlexE link.
   For a FlexE client, the expected value of FlexE
   parameters to be received will be the same as the values
   of those parameters configured in the transmit direction
   on the same PE, thus the expected parameters are not
   needed to be configured explicitly. If the received
   parameters are not the same values as those parameters
   configured locally, a PE should report the mismatch to
   the SDN controller/NMS. Examples of mismatch may include:
   FlexE group number mismatch, FlexE PHY number mismatch,
   Calendar configuration Mismatch, and etc.).



3. Requirements

   This section summarizes the management requirements of
   FlexE interfaces.

   a). Support of a flexible FlexE group bonding with one to
   254 Ethernet PHYs, the Ethernet PHY types may include 50
   GBASE-R, 100GBASE-R, 200GBASE-R and 400GBASE-R.

   b). Support add/remove Ethernet PHYs to/from a FlexE
   group, the range of FlexE PHY number still follows a).

   c). Support of flexible FlexE client management in a
   FlexE group, and the total clients number can be in a
   range of from 0 to a value equal to the maximum number of
   slots in the FlexE group (that is, each client is
   allocated a single slot).

   d). Support add/delete/resize FlexE clients in a FlexE
   group without impacts on the traffic of any existing
   FlexE clients in the same FlexE group, the range of FlexE
   client number still follows c).

   e). Support FlexE static or FlexE configurable operations.

   f). Support coordination of calendar updates and
   switchover by enabling FlexE negotiation between peer
   FlexE PEs.

   g). Support a client with bidirectional slot allocation
   while its bandwidth can be inferred from the allocated
   slot number and slot granularity.


Jiang, et al                Expires May 4, 2020          [Page 9]

Internet-Draft               FlexE Management PS      November 2019


   h). Support retrieval status of a FlexE group, a FlexE
   PHY, or a FlexE client.

   i). Management shall be compatible as much as possible
   with all OIF FlexE versions, including 1.0, 1.1, 2.0 and
   2.1.


4. Security Considerations

   This document gives the problem statements for FlexE
   management, and summarizes the requirements. As no
   solution is discussed in this document, no security
   concerns are raised.

5. IANA Considerations


   There are no IANA actions required by this document.


6. References

6.1. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to
             Indicate Requirement Levels", BCP 14, RFC 2119,
             March 1997

   [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase
             in RFC 2119 Key Words", BCP 14, RFC 8174, May
             2017

6.2. Informative References

   [FLEXE]   OIF, "Flex Ethernet 2.0 Implementation
             Agreement", FlexE 2.0, June 2018

   [flexe-usecases] Hussain, I., Valiveti, R., Pithewan, K.,
             "FlexE Usecases", draft-hussain-ccamp-flexe-
             usecases-01, work in progress

7. Acknowledgments

   The authors would like to thank Jinfeng Chen and Yalei
   Han for their contribution to this document.



Jiang, et al                Expires May 4, 2020         [Page 10]

Internet-Draft               FlexE Management PS      November 2019


   Authors' Addresses


   Yuanlong Jiang
   Huawei Technologies Co., Ltd.
   Bantian, Longgang district
   Shenzhen 518129, China
   Email: jiangyuanlong@huawei.com


   Fan Yang
   Huawei Technologies Co., Ltd.
   Huawei Campus, No. 156 Beiqing Rd.
   Beijing 100095
   Email: shirley.yangfan@huawei.com


   Italo Busi
   Huawei Technologies Co., Ltd.
   HUAWEI TECHNOLOGIES ITALIA Srl Centro Direzionale Milano 2
   Milan, Milan 20090, Italy
   Email: Italo.Busi@huawei.com


   Junfang Wang
   Fiberhome
   Email: wjf@fiberhome.com



















Jiang, et al                Expires May 4, 2020         [Page 11]