YANG Data Model for Flex E Interface Management

YANG Data Model for Flex. E Interface Management draft-jiang-ccamp-flexe-yang-02 Y. Jiang, X. He, W. Cheng, J. Wang, Y. Han Presenter: Yuanlong Jiang 106 th IETF – Singapore Copyright © 2004 Juniper Networks, Inc. Proprietary and Confidential www. juniper. net 1

Objective of Flex. E Interface Mgmt § Configuration of Flex. E Group as a network interface, binding of multiple Flex. E PHYs, configuration of Flex. E Clients and their slots in a Flex. E Group § Flex. E status retrieval including Flex. E Group, Flex. E PHYs and Flex. E clients § Support of interface management in SDN and NMS § Support of Flex. E 2. 1 & 2. 0, also backwards compatible with Flex. E 1. 1 &1. 0 106 th IETF – Singapore Copyright © 2004 Juniper Networks, Inc. Proprietary and Confidential www. juniper. net 2 2

Flex. E data plane in depth Flex. E Shim Flex. E Client 1 Flex. E Client 2 Flex. E Client 3 Flex. E PHY m Flex. E Client n Flex. E Slot … … … Flex. E Client 3 Flex. E PHY 2 Flex. E Slot Flex. E PHY 1 Flex. E Client 2 Flex. E Slot Node 2 Flex. E Shim Flex. E Slot Node 1 Flex. E Client n Flex. E Group Flex. E slot is a basic construct unit for Flex. E client and PHY in a Flex. E Group 106 th IETF – Singapore Copyright © 2004 Juniper Networks, Inc. Proprietary and Confidential www. juniper. net 3 3

Abstraction of Flex. E management Flex. E Slot Augmented from Flex. E Group Interface ietf-flexe-client ietf-flexe-group Flex. E Client Augmented from Flex. E Slot Flex. E Client ietf-interface Flex. E Client RFC 8343 … Flex. E PHY This draft ü Both Flex. E Group and Flex. E Client are modeled as network interfaces ü Flex. E Group is on the top layer, which contains multiple Flex. E Clients and PHYs ü Flex. E Clients can be added, deleted, configured, or resized with some Flex. E slots 106 th IETF – Singapore Copyright © 2004 Juniper Networks, Inc. Proprietary and Confidential www. juniper. net 4 4

YANG Tree Diagrams (updates in Red) module: ietf-interfaces-flexe-client module: ietf-flexe augment /if: interfaces/if: interface: +--rw flexe-client +--rw flexe-group +--ro mac-address +--rw group-number? uint 32 +--rw slot-granularity? slot-granularity-enumeration +--rw flexe-phy-type? flexe-phy-enumeration support the Flex. E calendar negotiation protocol +--rw calendar-protocol-enable? Boolean +--rw flexe-phy-list* [flexe-phy-if] | +--rw flexe-phy-if? if: interface-ref | +--rw phy-number uint 8 | +--ro phy-status? uint 8 | +--rw calendar-slot-list* [slot-id] | +--rw slot-id uint 8 | +--rw flexe-slot-status? slot-status-enumeration +--rw flexe-client-list* [client-id] | +--rw client-id uint 16 | +--rw flexe-client-if? if: interface-ref | +--rw client-slot-list* [client-slot-id] | | +--rw client-slot-id uint 8 | | +--rw mapped-phy-if? if: interface-ref support mapping of slots to a PHY | | +--rw mapped-slot-id uint 8 | +--ro flexe-client-status? uint 8 +--ro flexe-group-status? uint 8 106 th IETF – Singapore Copyright © 2004 Juniper Networks, Inc. Proprietary and Confidential www. juniper. net 5 5

CCAMP Minutes from IETF 105 § People think CCAMP is the place to start the work on Flex. E YANG § Need to check the Flex. E work done in other SDOs, such as ITU -T SG 15 § Need to look into other IETF YANG models for similar work § Needed more analysis on the pros and cons of the existing Flex. E YANG I-Ds 106 th IETF – Singapore Copyright © 2004 Juniper Networks, Inc. Proprietary and Confidential www. juniper. net 6 6

Flex. E progress in other SDOs § In July, OIF published Flex Ethernet 2. 1 Implementation Agreement (adds support of 50 GBASE-R PHY) § In September, during ITU-T Q 14/SG 15 interim meeting (Gothenburg), regarding Flex. E management information (MI) in G. 8023, it was agreed: • CCA &CCB are relevant only between the EMF and the atomic functions in a device; • CC, CR, & CA are controlled by EMF based on the client calendar configuration protocol or static configuration. They are not visible in the external interface • Tx and Ex are set to the same value • Some Flex. E MI need not to be visible in the external management/control interface 106 th IETF – Singapore Copyright © 2004 Juniper Networks, Inc. Proprietary and Confidential www. juniper. net 7 7

Similar work on YANG modules n IANA defines a type of LAG interface, i. e. , ieee 8023 ad. Lag, see RFC 7224 n 3 Predecessors of YANG interface with bonded Ethernet links: Ø IETF: Ethernet Bonding Interface Module, see Appendix B of RFC 8343 Ø IEEE: module ieee 802 -dot 1 ax Ø Open. Config: module openconfig-lacp Ø They are not Flex. E, but all of them are related to bonded Ethernet links, and modeled as a single interface 106 th IETF – Singapore Copyright © 2004 Juniper Networks, Inc. Proprietary and Confidential www. juniper. net 8 8

Why augment Flex. E from interface Advantages: § Inherit if: type, if: name and other attributes for conventional interface management § Simplicity, just use ‘leafref’ to reference to a Flex. E interface in applications § Unified style of naming, addressing, accessing and exception processing procedures as any other interfaces § Support of interface layering gracefully 106 th IETF – Singapore Copyright © 2004 Juniper Networks, Inc. Proprietary and Confidential www. juniper. net 9 9

Whether to model Flex. E instance or not § Do we need to model Flex. E instance? • Instance number can be automatically inferred from a Flex. E PHY number • For 50 G and 100 GBASE-R, Instance number=PHY number • For 200 GBASE-R, Instance number=PHY number*2 + [0, 1] • For 400 GBASE-R, Instance number=PHY number*4 + [0, 3] • Instance is internal, the only usage is to indicate unequipped instance in the case of 200 or 400 G, but the later can also be calculated by slot usage given the unavailable slots are always located in the end of a PHY slot list (i. e. , the highest numbered instance on a Flex. E PHY gets unequipped firstly) • Furthermore, Flex. E instance not exist in Flex. E 1. 1 or Flex. E 1. 0, thus will not be compatible if it is modelled • Therefore, Flex. E instance is suggested not to be modeled 106 th IETF – Singapore Copyright © 2004 Juniper Networks, Inc. Proprietary and Confidential www. juniper. net 10 10

Whether to model CC, CR, and CA § Do we need to model CC, CR and CA? • If calendar negotiation protocol is enabled: dynamic signaling of CC, CR and CA is done automatically in the data plane (in the Flex. E Overhead), it is meaningless to configure or retrieve these ephemeral signaling states • If calendar negotiation protocol is disabled: CC, CR and CA are static • In both cases, NMS or SDN controller does not need to care • Therefore, CC, CR and CA are suggested not to be modeled 106 th IETF – Singapore Copyright © 2004 Juniper Networks, Inc. Proprietary and Confidential www. juniper. net 11 11

Whether to model both CCA & CCB § Do we need to model both CCA and CCB? • CCA & CCB are used for hitless client reconfiguration, one for active and one for backup; it also means writing to CCA & CCB at the same time will cause loss of traffic on all the Flex. E clients • If negotiation protocol is enabled: client configuration is always written to the backup calendar, and calendar switching to the backup can be hitless • If negotiation protocol is disabled: switching from the active to the backup is not needed, client configuration can be written to the active calendar directly • In both cases, SDN controller/NMS only needs to deal with a single calendar configuration, while the device knows whether CCA or CCB is actually used for all time • Therefore, CCA & CCB are suggested not to be modeled 106 th IETF – Singapore Copyright © 2004 Juniper Networks, Inc. Proprietary and Confidential www. juniper. net 12 12

Bidirectional symmetric vs. asymmetric l Do we need to configure both TX & RX parameters? p Flex. E IA only discusses the configuration of a unidirectional client p The signaling of CR and CA relies on a bidirectional overhead channel in the same Flex. E Group p The Flex. E links (including each of the bonding PHYs) are always bidirectional symmetric p Flex. E clients are always reserved with the same number of slots (from which the bandwidth can be calculated) in both directions p Therefore, bidirectional symmetric parameters are more reasonable, there is no need to model TX & RX parameters separately 106 th IETF – Singapore Copyright © 2004 Juniper Networks, Inc. Proprietary and Confidential www. juniper. net 13 13

Where to model Flex. E Slot list 106 th IETF – Singapore Copyright © 2004 Juniper Networks, Inc. Proprietary and Confidential www. juniper. net 14 14

In summary-main differences draft-jiang-ccamp-flexe-yang draft-xiaobn-ccamp-flexe-yang-mod Flex. E Group modeled as a new interface, more conventional Flex. E-Groups is just a new container Flex. E Instance is not modeled Flex. E Instance is modeled, not backwards compatible CC, CR and CA are not modeled CC, CR and CA are modeled A single calendar is modeled, independent of CCA/CCB Both CCA & CCB can be configured, but actually it will defeat the purpose of hitless switching Bidirectional symmetric, not TX & RX Both TX & RX parameters are modeled Slot list modeled on each Flex. E PHY, unused slots are readily indicated in the calendar-slot-list Used slots modeled on Flex. E Instance when they are allocated to a client; unused slots can only be determined after traversing all flexe-clients Flex. E client is contained in Flex. E group, Flex. E-clients is outside of Flex. E-groups, it means Flex. E client will only exist if thus Flex. E client can be instantiated its Flex. E group exists a Flex. E group, more error prone 15 106 th IETF without – Singapore Copyright © 2004 Juniper Networks, Inc. Proprietary and Confidential www. juniper. net 15

In summary-other differences draft-jiang-ccamp-flexe-yang draft-xiaobn-ccamp-flexe-yang-mod 4 tier YANG tree, flat & simple 7 tier YANG tree, deep & complex Only slots are modelled, bandwidth can be calculated from slots*granularity Both slots and bandwidth are modeled, but how to provide the bandwidth value consistently may pose a challenge Only local parameters are included, no Both local and remote PHYs are remote PHY needs to be configured included in the model, thus more complex Support status retrieval of Flex. E Group, PHYs and clients No support of status retrieval Client number is local to a Flex. E Group, thus scalable in a large network (236 clients in maximum together with 20 bits of Flex. E Group) As a single YANG key, client number must be globally unique independent of a Flex. E Group, thus not scalable in a large network (only 216 clients in maximum) 106 th IETF – Singapore Copyright © 2004 Juniper Networks, Inc. Proprietary and Confidential www. juniper. net 16 16

Next Step § Update the draft according to WG feedbacks § Call for WG adoption 106 th IETF – Singapore Copyright © 2004 Juniper Networks, Inc. Proprietary and Confidential www. juniper. net 17 17

Thank You Copyright © 2004 Juniper Networks, Inc. Proprietary and Confidential www. juniper. net 18

Flex. E overview Flex. E Shim Flex. E Clients Node 1 Bonded Ethernet PHYs (Flex. E Group) Node 2 Flex. E support: • • • Bonding of ETH PHYs (1~n) Sub-rates of ETH PHY (minimum of 5 G) Channelization within a PHY or a group of bonded PHYs (5 G ~ m*5 G) 106 th IETF – Singapore Copyright © 2004 Juniper Networks, Inc. Proprietary and Confidential www. juniper. net A. 1 19

Flex. E Shim Flex. E mux functions (200 GBASE-R) Node 1 106 th IETF – Singapore Copyright © 2004 Juniper Networks, Inc. Proprietary and Confidential www. juniper. net A. 2 20

Flex. E demux functions (200 GBASE-R) Flex. E Shim Node 2 106 th IETF – Singapore Copyright © 2004 Juniper Networks, Inc. Proprietary and Confidential www. juniper. net A. 3 21

Flex. E slots and overhead Flex. E shim uses a calendar which assigns 66 B block positions (or Calendar slots) to each of the Flex. E Clients. For a Flex. E Group composed of n 100 G Flex. E Instances, the logical length of the calendar is 20 n (slots). On a 100 G Flex. E Instance, a Flex. E Overhead (8 blocks) occurs once per 104. 77μs. 106 th IETF – Singapore Copyright © 2004 Juniper Networks, Inc. Proprietary and Confidential www. juniper. net A. 4 22

Flex. E Overhead Frame and Multiframe of each 100 G Flex. E Instance 106 th IETF – Singapore Copyright © 2004 Juniper Networks, Inc. Proprietary and Confidential www. juniper. net A. 5 23

CCA CCB For a 100 G Flex. E Instance, a Flex. E Multiframe consists of 32 Overhead Frames 106 th IETF – Singapore Copyright © 2004 Juniper Networks, Inc. Proprietary and Confidential www. juniper. net A. 6 24

Flex. E Negotiation Protocol by Overhead (An example) Node 2 Rx Node 1 Tx C=0 / CR=0 Transmit in CCA Update Client Calendar B Time Set CR=1 CA=1 Confirm Receive by CCA Overhead n Set C=1 Overheadn+1 Transmit in CCB C=1 / CR=0 106 th IETF – Singapore Copyright © 2004 Juniper Networks, Inc. Proprietary and Confidential www. juniper. net Receive by CCB A. 7 25