idnits 2.17.1 draft-jiang-ccamp-flexe-ifmps-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 4, 2019) is 1636 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Y. Jiang 2 Internet Draft F. Yang 3 Intended status: Informational I. Busi 4 Huawei 5 J. Wang 6 Fiberhome 7 Expires: May 2020 November 4, 2019 9 Problem Statements of FlexE Interface Management 10 draft-jiang-ccamp-flexe-ifmps-00 12 Abstract 14 This document outlines the problem statements for FlexE interface 15 management; it also gives an analysis of configuration requirements 16 for Flex Ethernet (FlexE) interface management. Requirements on FlexE 17 interface management are summarized in the end. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute working 26 documents as Internet-Drafts. The list of current Internet-Drafts is 27 at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 4, 2020. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction ........................................ 2 54 1.1. Conventions used in this document ................ 3 55 1.2. Terminology ...................................... 4 56 2. Problem statements .................................. 4 57 2.1. Overview of FlexE management ..................... 4 58 2.2. Considerations on parameters in FlexE Overhead ... 5 59 2.2.1. Static or configurable .......................... 6 60 2.2.2. Negotiation enable or not ....................... 7 61 2.2.3. Management of FlexE clients ..................... 7 62 2.3. Considerations on bidirectional transport ........ 8 63 3. Requirements ........................................ 9 64 4. Security Considerations ............................ 10 65 5. IANA Considerations ................................ 10 66 6. References ......................................... 10 67 6.1. Normative References ............................ 10 68 6.2. Informative References .......................... 10 69 7. Acknowledgments .................................... 10 71 1. Introduction 73 The Flex Ethernet (FlexE) 2.0 Implementation Agreement 74 [FLEXE] defined by the OIF provides the support of a 75 variety of Ethernet MAC rates that may or may not 76 correspond to any existing Ethernet PHY rate. This 77 includes MAC rates that are both greater than (through 78 bonding) and less than (through sub-rate and 79 channelization) the Ethernet PHY rates used to carry 80 FlexE. 82 Besides 100GBASE-R PHYs as supported in FlexE 1.0, FlexE 83 2.0 supports the bonding of 200GBASE-R PHYs or 400GBASE-R 84 PHYs respectively. FlexE 2.1 further supports the bonding 85 of 50GBASE-R PHYs. 87 According to [FLEXE], FlexE supports the following 88 features: 90 - Bonding of multiple ETH PHYs (1~254) 91 - Sub-rates of ETH PHY (minimum of 5G to maximum capacity 92 of bandwidth in a PHY) 94 - Channelization within a PHY or a group of bonded PHYs 95 (5G ~ k*5G, combination of multiple slots, where each 96 slot can be allocated from any PHY) 98 In the FlexE, multiple Ethernet PHYs (each PHY can 99 further consist of one or more FlexE Instances) are 100 bonded into a FlexE Group, and the total capacity of the 101 FlexE Group is represented as a collection of slots (e.g., 102 each slot has a granularity of 5Gbps or 25Gbps). Based 103 on their bandwidth needs, FlexE Clients are each 104 allocated with one or more slots in a FlexE group. The 105 FlexE mechanism operates by using a calendar consisting 106 of these slots. 108 This calendar is partitioned into sub-calendars for each 109 PHY (earlier than FlexE 2.0) or sub-calendars for each 110 FlexE instance (FlexE 2.0 and above). For example, the 111 calendar for a FlexE Group composed of n 100G PHYs is 112 partitioned into 20n slots (each slot representing 5Gbps 113 of bandwidth when the slot granularity is 5Gbps). 115 Some FlexE use cases are introduced in details in [flexe- 116 usecases]. 118 This document describes the problem statements for FlexE 119 interface management to support the transport of FlexE 120 clients over a FlexE Group between two FlexE nodes. The 121 equipment can be routers or optical transport products, 122 which can support FlexE interfaces. Multiple hops of 123 FlexE aware transport in OTN or MTN is out of the scope 124 of this document. 126 1.1. Conventions used in this document 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 129 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", 130 "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in BCP 132 14 [RFC2119] [RFC8174] when, and only when, they 133 appear in all capitals, as shown here. 135 1.2. Terminology 137 Terminologies used in this document are extracted from 138 [FLEXE]. 140 FlexE: Flex Ethernet. 142 FlexE Client: An Ethernet flow based on a MAC data rate 143 that may or may not correspond to any Ethernet PHY rate, 144 the format of the FlexE Client is simply a logically 145 serial stream of 66B blocks at a given rate. 147 FlexE Group: A FlexE Group is composed of from 1 to n 148 Ethernet PHYs. 150 FlexE Instance: A FlexE Instance is a unit of information 151 consisting of 100G of capacity able to carry FlexE Client 152 data, together with its associated overhead. 154 Ethernet PHY: an entity representing Ethernet Physical 155 Coding Sublayer (PCS), Physical Media Attachment (PMA), 156 and Physical Media Dependent (PMD) layers. Each PHY is 157 consisted of one or more FlexE Instance (e.g., a 158 400GBASE-R PHY has four FlexE Instances). 160 FlexE Calendar: The total capacity of a FlexE Group is 161 represented as a collection of slots. The calendar for a 162 FlexE Group composed of n PHYs is represented in each PHY 163 as an array of slots (e.g., each representing 5Gbps of 164 bandwidth), i.e., calendar-slot-list. 166 CCA: Calendar Configuration A 168 CCB: Calendar Configuration B 170 2. Problem statements 172 2.1. Overview of FlexE management 174 Figure 1 depicts the overview diagram of FlexE management 175 for a FlexE Group between PE1 and PE2, where PE1 and PE2 176 are network equipments such as routers or OTN products. 177 SDN/NMS may control or manage the FlexE Group between PE1 178 and PE2 by interactions with PE1 and PE2 separately (by 179 using Netconf or Restconf to connect with a management or 180 control agent on each PE node). 182 +-----------+ 183 | | 184 | SDN/NMS | 185 | | 186 +-----------+ 187 // \\ 188 // \ 189 // \\ 190 // \ 191 // \\ 192 +-----------* FlexE Group *-----------+ 193 | | -- PHY1 | | 194 | PE1 +----/--\----------------+ PE2 | 195 | | | | PHY2 | | 196 | +---+----+---------------+ | 197 | | | | PHYn | | 198 | +---+----+---------------+ | 199 | | \ / | | 200 | | -- | | 201 | | | | 202 +-----------+ +-----------+ 204 Figure 1: FlexE management overview 206 2.2. Considerations on parameters in FlexE Overhead 208 The OIF specifies how the configuration and verification 209 of a FlexE Group can be realized in Section 7.3 of 210 [FLEXE]. A FlexE Overhead Frame is defined in [FLEXE] to 211 convey FlexE group specific information from PE1 to PE2, 212 including configuration information (FlexE Group Number, 213 FlexE Map, FlexE PHY/Instance Number, CCA and CCB), 214 status information (RPF) and signaling information (CC, 215 CR and CA). 217 The configuration information in the overhead frame is 218 used by the receiving side to verify that both ends are 219 properly configured with the same set of values in a 220 FlexE Group. If PE2 finds out that the configuration 221 information in the overhead sent from PE1 does not match 222 its own configuration, a mismatch alarm should be raised. 224 Note: Two calendar configurations are used in the FlexE 225 data plane to facilitate reconfiguration, i.e., CCA and 226 CCB. They are actually two lists (e.g., each list is 227 20*2Bytes for a PHY of 100GBASE-R; or 4*20*2Bytes for a 228 PHY of 400GBASE-R) wherein each list item indicates the 229 client number carried in a calendar slot. At any given 230 time, only one of the calendar configurations is active 231 and used for mapping the FlexE Clients into the FlexE 232 Group and demapping the FlexE Clients from the FlexE 233 Group. When a switch of calendar configurations 234 adds/removes/resizes FlexE Clients in a FlexE Group, the 235 switching does not affect existing clients whose size and 236 calendar slot assignments are not changed. 238 Status information indicates status of the bonded PHYs, 239 currently only RPF (Remote PHY Fault) is defined in 240 [FLEXE], which informs the far-end of a locally detected 241 failure of the PHY if set to one. 243 The signaling information can be used to coordinate the 244 switching from the active calendar configuration (e.g., 245 CCA) to the backup calendar configuration (e.g., CCB) 246 between PE1 and PE2. As described in 7.3.4 of [FLEXE], CC, 247 CR and CA are used to coordinate the switching of 248 calendar A to calendar B or vice versa between the FlexE 249 mux and FlexE demux (i.e., the source and the sink of a 250 FlexE group). The protocol is optional to implement. 252 2.2.1. Static or configurable 254 If the FlexE is static, a FlexE Group is composed of a 255 fixed number of FlexE PHYs, e.g., simple bonding for a 256 single fixed client; fixed calendar configuration. That 257 means, there is no need to configure a device or it is 258 impossible to configure the device. Some simple 259 implementations only support static configuration. 261 If the FlexE is configurable, the FlexE parameters can be 262 controlled by a SDN controller or be configured by a 263 network management system (NMS). 265 A FlexE static PE usually interconnect with another PE in 266 FlexE static (it is required that both PEs implement a 267 FlexE group with exact the same set of fixed parameter 268 values). However, sometimes there is a need to 269 interconnect one FlexE static PE with another PE in FlexE 270 configurable if the latter is properly configured with 271 the same set of fixed parameter values. 273 2.2.2. Negotiation enable or not 275 [FLEXE] uses two calendar configurations (i.e., CCA and 276 CCB) to facilitate client reconfiguration. Furthermore, 277 Section 7.3 of [FLEXE] specifies a dynamic negotiation 278 protocol (by signaling in the FlexE overhead) for the 279 automatic switching of calendars in a FlexE Group. If 280 this negotiation protocol is enabled (if one PE enables 281 negotiation, the other PE MUST enable negotiation too), a 282 receiving PE (i.e., slave) can further extract the 283 configuration information (particularly CCA and CCB) from 284 the FlexE overhead and multi-frame sent from a sending PE 285 (i.e., master). 287 It seems that the slave does not need to configure any 288 FlexE parameters if negotiation protocol is enabled. 289 However, from the viewpoint of bidirectional transport, a 290 receiving PE in one direction is also acting as a sending 291 PE in the other direction. Furthermore, FlexE group and 292 its bonding PHYs must be configured firstly so that FlexE 293 overhead channel can be set up for the signaling protocol 294 to work properly. Therefore, FlexE configuration is 295 needed on both side of PEs even if negotiation is enabled. 297 Since the dynamic signaling of CC, CR and CA is done 298 automatically in the data plane (especially, CR and CA 299 are request and acknowledgement exchanged dynamically 300 over the FlexE overhead, CC decides whether CCA or CCB is 301 active), the mechanism works on the FlexE data plane 302 independent from the management plane. Exposing all these 303 signaling information to the management plane is not only 304 unnecessary, but also greatly complicates the operations 305 of FlexE. Thus, it is not needed to configure or retrieve 306 these ephemeral signaling states. 308 2.2.3. Management of FlexE clients 310 The following management of FlexE clients needs to be 311 supported: 313 -Add a client or clients 314 -Delete a client or clients 316 -resize a client or clients 318 -adjust slot locations for a client or clients 320 If the negotiation protocol is not enabled, management of 321 FlexE clients (add/delete/resize/adjust) usually is a 322 sequential action to the current calendar of each FlexE 323 PE, and retrieval of the calendar configuration values is 324 also based on the active calendar. Thus, synchronous 325 switching from the active calendar configuration to the 326 backup calendar configuration is not needed. However, 327 some client traffic may be lost during the 328 reconfiguration. 330 If the negotiation protocol is enabled, management of 331 FlexE clients (add/delete/resize/adjust) usually is a 332 sequential action to the backup calendar of each FlexE PE. 333 Then dynamic negotiation as described in Section 2.2.2 334 controls peer PEs to switch the backup calendar 335 configuration into the active calendar configuration 336 synchronously. The switching is hitless since the client 337 traffic is not lost during the reconfiguration, thus it 338 is recommended to be the default working mode. Moreover, 339 retrieval of the calendar configuration values SHOULD be 340 based on the new active calendar after protocol 341 convergence (the convergence time is expected to be 342 around 10ms calculated according to [FLEXE]). 344 In either cases, the management plane only needs to deal 345 with a single calendar, and there is no need to monitor 346 whether the calendar is CCA or CCB from the SDN/NMS point 347 of view. 349 2.3. Considerations on bidirectional transport 351 OIF only discusses the configuration of a unidirectional 352 client. 354 In fact, the overhead signaling of CR and CA relies on a 355 bidirectional channel in the same FlexE Group. 357 Furthermore, the FlexE links (including each of the 358 bonding PHYs) are always bidirectional, and FlexE clients 359 are usually reserved with the same number of slots (or 360 bandwidth) in both directions over the same FlexE link. 361 For a FlexE client, the expected value of FlexE 362 parameters to be received will be the same as the values 363 of those parameters configured in the transmit direction 364 on the same PE, thus the expected parameters are not 365 needed to be configured explicitly. If the received 366 parameters are not the same values as those parameters 367 configured locally, a PE should report the mismatch to 368 the SDN controller/NMS. Examples of mismatch may include: 369 FlexE group number mismatch, FlexE PHY number mismatch, 370 Calendar configuration Mismatch, and etc.). 372 3. Requirements 374 This section summarizes the management requirements of 375 FlexE interfaces. 377 a). Support of a flexible FlexE group bonding with one to 378 254 Ethernet PHYs, the Ethernet PHY types may include 50 379 GBASE-R, 100GBASE-R, 200GBASE-R and 400GBASE-R. 381 b). Support add/remove Ethernet PHYs to/from a FlexE 382 group, the range of FlexE PHY number still follows a). 384 c). Support of flexible FlexE client management in a 385 FlexE group, and the total clients number can be in a 386 range of from 0 to a value equal to the maximum number of 387 slots in the FlexE group (that is, each client is 388 allocated a single slot). 390 d). Support add/delete/resize FlexE clients in a FlexE 391 group without impacts on the traffic of any existing 392 FlexE clients in the same FlexE group, the range of FlexE 393 client number still follows c). 395 e). Support FlexE static or FlexE configurable operations. 397 f). Support coordination of calendar updates and 398 switchover by enabling FlexE negotiation between peer 399 FlexE PEs. 401 g). Support a client with bidirectional slot allocation 402 while its bandwidth can be inferred from the allocated 403 slot number and slot granularity. 405 h). Support retrieval status of a FlexE group, a FlexE 406 PHY, or a FlexE client. 408 i). Management shall be compatible as much as possible 409 with all OIF FlexE versions, including 1.0, 1.1, 2.0 and 410 2.1. 412 4. Security Considerations 414 This document gives the problem statements for FlexE 415 management, and summarizes the requirements. As no 416 solution is discussed in this document, no security 417 concerns are raised. 419 5. IANA Considerations 421 There are no IANA actions required by this document. 423 6. References 425 6.1. Normative References 427 [RFC2119] Bradner, S., "Key words for use in RFCs to 428 Indicate Requirement Levels", BCP 14, RFC 2119, 429 March 1997 431 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase 432 in RFC 2119 Key Words", BCP 14, RFC 8174, May 433 2017 435 6.2. Informative References 437 [FLEXE] OIF, "Flex Ethernet 2.0 Implementation 438 Agreement", FlexE 2.0, June 2018 440 [flexe-usecases] Hussain, I., Valiveti, R., Pithewan, K., 441 "FlexE Usecases", draft-hussain-ccamp-flexe- 442 usecases-01, work in progress 444 7. Acknowledgments 446 The authors would like to thank Jinfeng Chen and Yalei 447 Han for their contribution to this document. 449 Authors' Addresses 451 Yuanlong Jiang 452 Huawei Technologies Co., Ltd. 453 Bantian, Longgang district 454 Shenzhen 518129, China 455 Email: jiangyuanlong@huawei.com 457 Fan Yang 458 Huawei Technologies Co., Ltd. 459 Huawei Campus, No. 156 Beiqing Rd. 460 Beijing 100095 461 Email: shirley.yangfan@huawei.com 463 Italo Busi 464 Huawei Technologies Co., Ltd. 465 HUAWEI TECHNOLOGIES ITALIA Srl Centro Direzionale Milano 2 466 Milan, Milan 20090, Italy 467 Email: Italo.Busi@huawei.com 469 Junfang Wang 470 Fiberhome 471 Email: wjf@fiberhome.com