Re: [CCAMP] Comparison of Flex-E YANG model parameters

niu.xiaobing@zte.com.cn Sat, 07 March 2020 10:00 UTC

Return-Path: <niu.xiaobing@zte.com.cn>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 814E33A0F23; Sat, 7 Mar 2020 02:00:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.103
X-Spam-Level:
X-Spam-Status: No, score=0.103 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJ5pBoLa42M5; Sat, 7 Mar 2020 02:00:36 -0800 (PST)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B363F3A0F29; Sat, 7 Mar 2020 02:00:01 -0800 (PST)
Received: from mse-fl2.zte.com.cn (unknown [10.30.14.239]) by Forcepoint Email with ESMTPS id 0DD1FCA03FB30053B1B6; Sat, 7 Mar 2020 18:00:00 +0800 (CST)
Received: from kjyxapp04.zte.com.cn ([10.30.12.203]) by mse-fl2.zte.com.cn with SMTP id 0279xjQD033597; Sat, 7 Mar 2020 17:59:45 +0800 (GMT-8) (envelope-from niu.xiaobing@zte.com.cn)
Received: from mapi (kjyxapp04[null]) by mapi (Zmail) with MAPI id mid17; Sat, 7 Mar 2020 17:59:45 +0800 (CST)
Date: Sat, 07 Mar 2020 17:59:45 +0800
X-Zmail-TransId: 2b065e637091aff119ef
X-Mailer: Zmail v1.0
Message-ID: <202003071759451807041@zte.com.cn>
In-Reply-To: <MN2PR11MB4366253BE95D9A2C2BA91583B5E40@MN2PR11MB4366.namprd11.prod.outlook.com>
References: 202002281541303765060@zte.com.cn, MN2PR11MB4366253BE95D9A2C2BA91583B5E40@MN2PR11MB4366.namprd11.prod.outlook.com
Mime-Version: 1.0
From: niu.xiaobing@zte.com.cn
To: rwilton@cisco.com
Cc: jiangyuanlong@huawei.com, daniele.ceccarelli@ericsson.com, draft-jiang-ccamp-flexe-yang@ietf.org, draft-xiaobn-ccamp-flexe-yang-mod@ietf.org, ccamp@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn 0279xjQD033597
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/fZP5wlx6PmDB9n4oH-8qcTImc-k>
Subject: Re: [CCAMP] Comparison of Flex-E YANG model parameters
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ccamp/>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 07 Mar 2020 10:00:45 -0000
X-List-Received-Date: Sat, 07 Mar 2020 10:00:45 -0000

hi Rob,


Please see [xb3] inline.






B.R.


Xiaobing Niu











原始邮件



发件人:RobWilton(rwilton) <rwilton@cisco.com>
收件人:牛小兵10019881;jiangyuanlong@huawei.com <jiangyuanlong@huawei.com>;daniele.ceccarelli@ericsson.com <daniele.ceccarelli@ericsson.com>;
抄送人:draft-jiang-ccamp-flexe-yang@ietf.org <draft-jiang-ccamp-flexe-yang@ietf.org>;draft-xiaobn-ccamp-flexe-yang-mod@ietf.org <draft-xiaobn-ccamp-flexe-yang-mod@ietf.org>;ccamp@ietf.org <ccamp@ietf.org>;
日 期 :2020年03月03日 19:29
主 题 :RE: Re:[CCAMP] Comparison of Flex-E YANG model parameters




Hi Xiaobing,


 


Please see [RW2] inline …


 


 




From: niu.xiaobing@zte.com.cn <niu.xiaobing@zte.com.cn>
Sent: 28 February 2020 07:42
To: jiangyuanlong@huawei.com; daniele.ceccarelli@ericsson.com; Rob Wilton (rwilton) <rwilton@cisco.com>
Cc: draft-jiang-ccamp-flexe-yang@ietf.org; draft-xiaobn-ccamp-flexe-yang-mod@ietf.org; ccamp@ietf.org
Subject: Re:[CCAMP] Comparison of Flex-E YANG model parameters




 

hi Rob, Daniele, Yuanlong,

Based on previous discussion, I think we are moving forward, although a little slow. I support to make more progress.

Please check the comments with [xb2] for more consideration.

Thanks!

 

B.R.


Xiaobing NIU


 




原始邮件



发件人:Jiangyuanlong <jiangyuanlong@huawei.com>



收件人:Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>;Rob
 Wilton(rwilton) <rwilton@cisco.com>;牛小兵10019881;



抄送人:draft-jiang-ccamp-flexe-yang@ietf.org
 <draft-jiang-ccamp-flexe-yang@ietf.org>;draft-xiaobn-ccamp-flexe-yang-mod@ietf.org <draft-xiaobn-ccamp-flexe-yang-mod@ietf.org>;ccamp@ietf.org
 <ccamp@ietf.org>;



日期:2020年02月28日
 14:46



主题:RE: [CCAMP] Comparison of Flex-E YANG model parameters




Definitely I support this, and will be glad to work together with Rob and others who are interested on a common FlexE model.


I also think the initial model structure in the (https://github.com/rgwilton/flex-e-yang)
 is quite reasonable a start.


 


Thanks,


Yuanlong


 



From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
Sent: Thursday, February 27, 2020 10:35 PM
To: Rob Wilton (rwilton) <rwilton@cisco.com>;niu.xiaobing@zte.com.cn
Cc: draft-jiang-ccamp-flexe-yang@ietf.org; draft-xiaobn-ccamp-flexe-yang-mod@ietf.org; ccamp@ietf.org
Subject: RE: [CCAMP] Comparison of Flex-E YANG model parameters




 


“If that is a reasonable approach, then do you think that it would be possible for both sets of authors to get together to produce a combined
 updated draft that takes into account the suggestions below and the prior proposed outline structure (https://github.com/rgwilton/flex-e-yang)? 
 Perhaps this could be done somewhere on github, with issues opened for the particular points that need further discussion?  I’m happy to be in those author discussions if it helps, but probably will have limited time actually working on a draft.”


 


This is exactly what I was suggesting…thank Rob for reiterate the message.


 


Thanks,


 


Daniele 



 



From: CCAMP <ccamp-bounces@ietf.org>On
 Behalf Of Rob Wilton (rwilton)
Sent: den 21 februari 2020 19:06
To: niu.xiaobing@zte.com.cn
Cc: draft-jiang-ccamp-flexe-yang@ietf.org;draft-xiaobn-ccamp-flexe-yang-mod@ietf.org;ccamp@ietf.org
Subject: Re: [CCAMP] Comparison of Flex-E YANG model parameters




 


Hi Xiaobing,


 


Thanks for the comments.


 


I’ve given responses [RW] inline below, but please note that my aim here is just to come up with a common model that both sets of authors
 can agree as a starting point for further discussion.  I would suggest that the model should start relatively simple, but all the outstanding issues can and should be tracked, and the WG can discuss and decide whether or not the model should be extended to
 support each of those issues.


 


If that is a reasonable approach, then do you think that it would be possible for both sets of authors to get together to produce a combined
 updated draft that takes into account the suggestions below and the prior proposed outline structure (https://github.com/rgwilton/flex-e-yang)? 
 Perhaps this could be done somewhere on github, with issues opened for the particular points that need further discussion?  I’m happy to be in those author discussions if it helps, but probably will have limited time actually working on a draft.


 


Further comments inline.


 




From:niu.xiaobing@zte.com.cn <niu.xiaobing@zte.com.cn>
Sent: 21 February 2020 13:06
To: Rob Wilton (rwilton) <rwilton@cisco.com>
Cc: jiangyuanlong@huawei.com;ccamp@ietf.org;draft-xiaobn-ccamp-flexe-yang-mod@ietf.org;draft-jiang-ccamp-flexe-yang@ietf.org;shirley.yangfan@huawei.com
Subject: Re:Comparison of Flex-E YANG model parameters




 


Hi Rob,


I've added some comments with [xbn]. Please have a look.


 



B.R.


Xiaobing Niu


 


发件人:RobWilton(rwilton) <rwilton@cisco.com>


收件人:牛小兵10019881;jiangyuanlong@huawei.com <jiangyuanlong@huawei.com>;ccamp@ietf.org
 <ccamp@ietf.org>;draft-xiaobn-ccamp-flexe-yang-mod@ietf.org <draft-xiaobn-ccamp-flexe-yang-mod@ietf.org>;draft-jiang-ccamp-flexe-yang@ietf.org
 <draft-jiang-ccamp-flexe-yang@ietf.org>;



抄送人:shirley.yangfan@huawei.com <shirley.yangfan@huawei.com>;



日期:2020年02月21日
 01:53



主题:RE:
 Re:Comparison of Flex-E YANG model parameters




Just pinging this thread to see if any of the authors had further thoughts on this.


 


I guess that the clock is ticking to get an updated model & draft before IETF 107, and it would be good to keep this work progressing.


 


Thanks,


Rob


 


 




From:niu.xiaobing@zte.com.cn
 <niu.xiaobing@zte.com.cn>
Sent: 31 January 2020 16:40
To: jiangyuanlong@huawei.com; Rob Wilton (rwilton) <rwilton@cisco.com>
Cc: ccamp@ietf.org; draft-xiaobn-ccamp-flexe-yang-mod@ietf.org;draft-jiang-ccamp-flexe-yang@ietf.org;shirley.yangfan@huawei.com
Subject: Re:Comparison of Flex-E YANG model parameters




 

Hi Rob, Yuanlong

Thanks for your detailed analysis and trade-off recommendation.


Recently, several contributions about FlexE have been discussed in ITU-T SG15 meeting and some more will be discussed in following days.  And more clear requirements about FlexE processing
 functions and related configuration are expected. I think that will be helpful to the model.


 

B.R.

Xiaobing Niu

 


 


原始邮件



发件人:Jiangyuanlong <jiangyuanlong@huawei.com>



收件人:Rob Wilton (rwilton) <rwilton@cisco.com>;ccamp@ietf.org <ccamp@ietf.org>;draft-xiaobn-ccamp-flexe-yang-mod@ietf.org
 <draft-xiaobn-ccamp-flexe-yang-mod@ietf.org>;draft-jiang-ccamp-flexe-yang@ietf.org <draft-jiang-ccamp-flexe-yang@ietf.org>;



抄送人:Yangfan (IP Standard) <shirley.yangfan@huawei.com>;



日期:2020年01月31日
 07:36



主题:RE:
 Comparison of Flex-E YANG model parameters




Hi Rob,

Thanks a lot for the detailed comments, I agree with most of them (except several minor items, I will comment on them later).
I will be glad to work with you and the other authors on a common FlexE model draft.

Cheers,
Yuanlong

-----Original Message-----
From: Rob Wilton (rwilton) [mailto:rwilton@cisco.com] 
Sent: Thursday, January 30, 2020 12:58 AM
To: ccamp@ietf.org; draft-xiaobn-ccamp-flexe-yang-mod@ietf.org; draft-jiang-ccamp-flexe-yang@ietf.org
Subject: Comparison of Flex-E YANG model parameters

Hi,

Sorry for the delay.

After I think that we reached rough agreement on Flex-E model structure, I have now (with my limited knowledge) gone through the flex-e configuration parameters in draft-xiaobn and draft-jiang.  I think that I have hopefully given comments on all areas of the configuration.  I think that some aspects will be easier to resolve and reach conclusion on than other parts.

Hence, to try and make forward progress, I suggest that we try and defer getting stuck in discussion on the following topics:

  1.  Whether we need to have explicit configuration for both A and B calendars or not.  The model will definitely be simpler for client if this is not required, so I would recommend that we assume that it is not required, try and resolve the other points and then come back to this potentially thorny issue.


[xbn] If no explicit configuration for A/B calendar, some scenarios could not be supported.


  2.  Whether we need to have the "expected" configuration leaves.  I'm not sure I fully understand the intent of this, but I suspect that the intent is to use the calendar protocol as a way of checking that both sides are correctly configured.  My suggestion, to simplify the model, is to assume that in this case that the RX and TX calendar for client interfaces are the same, and hence this configuration could probably be expressed through a different "calendar-protocol-enable/tx-calendar-neg" setting.  But again, I suspect that this might be another can or worms that we might want to try and keep the lid on for the moment whilst we get agreement for the other parts of the model.  But, of course, this could be handled through a vendor or standard augmentations, or YANG features, but I still have a preference is trying to keep the base model as simple as we can.


 [xbn] Setting expected configuration info is aiming to strictly check the configuration in both ends. It can be relieved as you recommended above.


[RW]
Okay, so I think that I understand that you are happy to defer this issue for the moment (perhaps track the issue on a github repro).


Barring these two points, you will see that I have tried to give a suggestion for the other configuration items, with an aim to try and get a compromise starting model that the authors and WG can move forward with.

Based on the comments that I receive, I propose updating the YANG model here (https://github.com/rgwilton/flex-e-yang).  If we do manage to find common ground over the next week or two, hopefully it will be possible for both sets of authors to take the combined model, polish it, and work together on a common FlexE model draft?

FlexE Group, Bonded-phy, instance and client configuration comparison:

(A) Group level configurable attributes:
    (A 1) Both drafts define a per group slot granularity (slot-granularity/cal-slot-gran)
     - both represented by an enum
     - both allow 5g and 25g (as per the OIF standard)
     - draft-jiang draft also allows "slot-others".
     - draft-jiang defines a default value (5g), but draft-xiaobn does not.
     - My recomendation:
       - The base model should only include 5g and 25g, because that is what is in the spec, and vendors can always deviate this leaf if required to support non-standard values.
       - I think that a default value is useful and should be defined, but possibly using 25g as the default because it is more forward looking (as bandwidths increase).
      [xbn] Maybe 5G slot is better, because 5G slot is more flexible to support various clients( e.g. BW lesss than 25G).


[RW] Sure, I think that this is a minor detail.


    (A 2) Both drafts support configuring Flex-E phy type (100g, 200g, 400g, 50g) (flexe-phy-type)
     - I'm not sure that this configuration is required, or just useful as an extra check.
     - Vendors could always deviate add "mandatory" if required.
     - I suggest that this leaf should be optional, and have no default value defined.

    (A 3) draft-xiaobn supports limiting the bandwidth for a flex-e group (flexe-gp-avb-bw)
     - This configuration seems to act as an additional constraint.  I don't see any harm in this configuration, but it seems somewhat redundant (given the bandwidth can be calculated for each member interface), and hence as a starting point, my preference would be to leave this out of a standard FlexE configuration data model.
     [xbn]When you take the Unequipped instance and Unavailable slot into consideration, the bandwidth can provide some sense. It gives the total BW directly.


[RW] Operationally reporting the available bandwidth definitely makes sense (which would take into account unavailable
 slots, etc).  But I’m less convinced of it as a configuration item.  E.g. what would it mean if the configured value doesn’t match the real bandwidth?  Would the config be rejected?


 [xb2] Could we make it readable only? When a slot is used or released, the available bandwidth changes accordingly. That can be used to jusge whether
 there is enough bandwdth available for a new requirement.


[RW2] By read-only, I assume that you mean config false, if so I think that would be fine.


   [xb3] Yeah, config false.


    (A 4) Both drafts seem to have a mechanism to control the calendar protocol (calendar-protocol-enable/tx-calendar-neg):
      - I would suggest changing the name of this leaf to "calendar-mode", and use an enumeration for future extensibility.
      - Enumeration choices could be
         "Static", - calendar configuration is static (and assumed to be the same for both RX and TX), calendar protocol information is ignored.
         "Verified" - calendar configuration is static (and assumed to be the same for both RX and TX), calendar protocol information is checked, otherwise the client interface is kept down in an errored state?  E.g. replacing the need for the "expected" configuration values in draft-xiaobn.

    [xbn] Originally this kind of ‘verifiy function’ was considered in ‘Static’ mode. Here you put it in a ‘Verified’ mode, and it is OK.

[RW] Okay.

 


         "Master-Slave" calendar configuration is static for TX, RX is determined from the calendar protocol (although perhaps should use different terminology for political correctness)
      - Having a default value for the calendar protocol makes sense, but I don't know what the appropriate default is.

    (A 5) draft-xiaobn defines reply-ca-mode:
      - I'm not quite sure what this leaf is for, and hence I question whether it is required since it appears to be somewhat implementation specific.


     [xbn] After recieving the CReq, the demux may delay for some time and then reply with the CA ,while not immediately reply. Some reasons for
 that are described in FlexE IAs. To consider both cases, the moment of replying CA should be flexible.


[RW] Okay, ideally it wouldn’t be necessary to expose this sort of detail into the model.  I would suggest that
 we leave this out to start off with, and raise a issue to track and discuss.


  [xb2] Could we leave this open that the default behaviour is replying CA immediately and other behaviour may be augmented later?


[RW2] Yes, but I don’t really know about the CA response.  I think that this should follow whatever the Flex-E spec states.  I.e. possibly the YANG model should say nothing
 about this at all.


  [xb3] Yeah, we should follow the FlexE spec. For more information about the CA bit, please refer to middle part of Page 31 in the FlexE IA 2.0. here it shows as follows,   


When the FlexE demux is prepared to accept the switch of calendar configuration, it 


informs the FlexE mux by changing its CA bit to match the incoming CR bit on all 100G 


FlexE Instances of the FlexE Group beginning with the same overhead frame in the 


overhead positions on each 100G FlexE Instance. When this occurs is application 


specific. At the earliest, it occurs once the assignment of every calendar slot in the offline 


configuration has been received by the FlexE demux in a FlexE overhead frame with a 


good CRC after the change of the incoming CR bit. But the CA bit indication may be 


delayed for a variety of reasons: for example, software may need to be prepared for the 


incoming bandwidth change, for example in SDN applications. 


    From above description in italic, we can get to the conclusion that there are different replying choices for the CA bit. That should be taken into consideration in Yang model. One of the implementations is to config reply-ca-mode just as shown in draft-xiaobn.






(B) Bonded-phy level configuration:
    (B 1) draft-xiaobn contains a "remote-phy-interface" as an interface-ref.  This configuration cannot work as an interface-ref (because it would attempt to validate against the local device's interface list).  I suspect that this isn't really configuration at all, but possibly just documentation.  As a starting point, my preference would be to leave this out of a standard FlexE configuration data model.  Vendors could always augment this in, with little interop issues.
    (B 2) Both drafts define mechanisms under the bonded-phy/[instance for draft-xiaobn] to specify the unavailable slots.  Rather than defining these as lists of unavailable slots, I would merge these into a single per bonded-phy leaf of ranges of what are the available slots, and if the leaf is not configured then all slots (for available instances) can be used.
        E.g. I am suggesting a per bonded-phy leaf:
            available-calender-slots = "1-15, 19, 20-29"


     [xbn] It’s ok. The slot number may be not
 consecutive.


[RW] Okay.


(C) Instance configuration:
    (C 1) draft-xiaobn has explicit support for flex-e "instances" from FlexE 2.1,(e.g. a 200G PHY is represented as 2x100G instances, a 400G PHY, has 4x100 instances).
     - I would think that any instance configuration should naturally be under the PHY, since from the spec, it seems to be phy specific, and relative to the phy.
     - FlexE has the ability to disable instances, but it must always be the highest instance numbers on a phy that are disabled.
        * One option is that this could be represented by a single configurable uint8 under the bonded-phy that indicates the number of supported-instances and defaults to all instances being supported if not configured.  [Note - this configuration is probably equivalent to the "uneq-flexe-instance", but in reverse sense and represented in a more concise way.]
        * An alternative option would be to infer which instances are disabled from the available-calendar-slot list.  E.g. for a 400G interfaces, stating available-slots="1-39" would imply that only instances 1 and 2 are in use, and instances 3 and 4 are disabled.
     - Otherwise I don't think that it is necessary to configure/define a separate calendar slot availability per instance.  I think that it will be more concise and simpler for clients if this is just configured under the bonded phy.  E.g., assuming 5G slots,  instance 0 would be slots 0-19, instance 1 would be slots 20-39, instance 2 would be slots 40-59, etc...


[xbn] OK


(D) "Expected configuration":
  (D 1) draft-xiaobn defines expected-group-number, expected-phy-map, expected-cal-cfg.
    - I don't think that these configuration items should be required.  These settings should either just be (i) regular configuration, i.e. covered by the other configuration items, or learned from the peer (e.g. if it can be carried via protocol).
    [xbn] It's related to the verifying function mentioned previously.


[RW] Okay, great.  Thanks for confirming that these are not required.


 


(E) "Calendar configuration"
  (E 1) draft-xiaobn defines tx-calendar, rx-calendar (and also tx-calendar-neg but that has been covered above).
   - I think that it is useful to be able to configure whether the A or B calendar is being used, defaulting to "A" if not specified.
   - I'm not convinced that the standard model should have rx-calendar. In the case that it is statically configured, I think that the standard model should assume that the RX and TX calendar are the same.

  [xbn] I think the unidirectional client service should also be considered.

[RW] Okay.  Can we initially start with the bidirectional only, and then raise an issue to discuss the unidirectional client service.  I think that it would be good to understand the real
 use cases here.

  [xb2] Ok. The bi-directional client service has more priorities compared with the uni-directional client service, and we suggest to keep track of the support of the uni-directional service.

[RW2] Okay.

 


(F) Client interface configuration
(F 1) From reading the OIF-FlexE spec, on the wire it looks like clients are bound to instances, but I don't think that this should be in the management model, it feels like it would be exposing unnecessary complexity.
   - draft-jiang allows each individual slot to be assigned to assigned to a phy and a slot on that phy.  This could end up being verbose.  E.g. 20 entries for a 100G client interface with 5G slot sizes.  Client ordering is explicitly specified by the client-slot-id leaf.
   - draft-xioabn maps to instance number and slot-id.  Client ordering isn't specified.  This would probably work if the list is "ordered-by user".
   - In both cases, I think that the configuration is a bit verbose, particularly for simple/normal configurations.  Hence, I would recommend a more compact format:
     - An ordered-by user list of phys, where for each phy the slots are specified in a range string, e.g. "1-10, 15-19".  The mapping from the client slot to phy slot is implicit from the client ordering of the phys and the slots.
     - This does effectively impose some restrictions (or simplifications):
       - The slots used by a client on a given phy are always in order, e.g.. I think that "10-1" or "6,3,2,9,5" should not be allowed.
       - You can't have some slots on one phy, then some on another phy, and then more on the first phy again.  All the slots on a given phy must be specified together (because the phy interface would be the list key).
     [xbn] It maybe work in this way after increasing or decreasing the width several times.


[RW] I still think that might be okay.  If the configuration is being done manually, then some of these changes
 could end up being service impacting, but if calendar negotiation was being used, then I think that this restriction should probably be okay (again, at least from a starting point)?


  [xb2] According to the restrictions above, the slot list configured for a client will be always ordered from
 lower number PHYs to higher number PHYs. That's OK.


 [xb2]There's a problem about the client and the client-interface under the FlexE group. we have talked about it.


   A client is Ethernent flow based on a MAC data rate. It can be generated within system or received from an Ethernet PHY. When configuring the client into a FlexE group, the client
 can be seen as an interface with MAC.


   In the proposed YANG model, the FlexE group includes PHYs, list of client-interface, and slots allocated for a client interface.  Because of the slots, the client-interface in Flexe
 group is diiferenet from the client that would be carried by the FlexE group, and they are two different kinds of interfaces. It's also one of the reason why Flexe-group is dfferent from LAG. They should be considered in different ways in the YANG model.


[RW2]


The “client-interface” under the flex-e group isn’t really the client-interface at all.  It is really just the configuration that is necessary to create the client interface, and I would see this as the configuration that controls
 creating the client interface.


 [xb3] I got it. The 'client-interface' only keeps the  necessary configuration information for the cliient as the client is mapped into the FlexE group.


Yes, the slots are logically a property of the FlexE group. But ultimately what is being configured here is a mapping from flex-e group calendar slots to client interfaces carrying useful data.  From a manageability aspect I
 think that it is much easier for clients to describe this relationship in the context of each flex-e client – I think that is also effectively what your model is doing.


 


We think the model should include client, slot and PHY three parts. The client should be mapped into( or binded to) one of the client-interface in the FlexE group.


The client can be numbered with (Node ID+client number) in order to make it unique and conveniently maintained. While the client-interface can be numbered in the scope of a FlexE group(
 e.g. 1,2,3) or a node(Node ID+x). Even both can be numbered in the same value, they are diferent in essence.


[RW2]


Sorry, but I don’t fully understand your description/explanation above.  Probably this is something that needs to be discussed verbally further.


 


I agree that FlexE should be modelled a bit differently from LAG.


 


Roughly using your terminology then what I am trying to model is:

The “client” is defined under the FlexE group.

The “client-interface” is defined under /if/interfaces/, and looks like any other physical Ethernet interface, but with the difference that its bandwidth could change dynamically on the fly.


 


There also needs to be a binding (as a leafref) between “client” defined under the flex-e group and the “client-interface” defined under /if/interfaces/.  In the model that I’ve currently proposed the mapping is keyed by interface
 name, but I think that you are asking that this be keyed by client-id instead, and be called “client” instead of “client-interface?  I still regard this as a relatively minor issue, and one that can be tracked via a issue and then discussed further.  I.e.
 I really think that this is a point discussion about the lifecycle of the client interface relative to the flex-e group configuration and what level of forward referenced configuration is required. Note, whatever we come up with here needs to be compatible
 with NMDA (RFC 8342).


  [xb3] OK, it's fine to keep the 'client-interface' intact.






(F 2) Explicit configuration for calendar A vs calendar B.
  - draft-xioabn allows both A and B calendars to be specified separately, draft-jiang does not.
  - My view is that configuring both A and B calendars complicates the model, and I would prefer that it is left out of an initial joint WG draft, but I understand that significant further discussion on this point is probably required.
    [xbn]Some scenarios about configuring A/B to specific value are described in FlexE IAs. If this is not considered, the model would not be applicable for some applications.


[RW2] Okay, but rather than explicitly configurating A and B calendars, it might be better to have a default calendar and an
 optional backup calendar, and then a separate config item to indicate which calendar is being used.  So, I agree that this should be discussed further, but was suggesting that we try and start from the simplest point and then add in the extra bits that are
 really required.


     [xb3]  OK, I agree with you to have a default calendar and an optional backup calendar, and then a separate config item to indicate which calendar is being used.


(F 3) rx calendar slots and expected calendar slots.
  - draft-xioabn allows, if the tx-calendar is in static mode, to specify the rx-calendar slots, and the expected A and B calendar slots.
  - I think that in static mode we should probably assume that RX calendar slots are the same as the TX calendar slots.
  - I don't think that the expected slots configuration should be required, or perhaps could be better modelled via the calendar protocol mode.
    [xbn] It’s related to two uni-directional flows with different BWs and directions. For example, in the same FlexE group, Flow
 A->Z uses slots[1, 2], while flow Z->A uses slots[2,3,4]. How to support this?


[RW] I think that for that more complex scenario we should rely on the calendar negotiation (for the standard
 model), but allow vendors to augment with this functionality if required.


  [xb2] It's a good idea to include a default calendar, optional backup calendar and configurable will-be-used calendar. That enables the network manager explicitly changes the
 calendar if he wants. 


[RW2] This will probably end up needing further discussion. I.e. whatever is decided here we need to make sure that the device doesn’t have to change the configuration.  I.e.
 configuring the device to use the backup calendar doesn’t change the configuration to being the primary calendar.  The client would need to explicitly configure that, as a second step, if required.


  [xb3] To simplify the model,  I would like not to take this feature into account currently and leave it for further discussion.


(F 4) Bandwidth
   - draft-xiaobn defines client inteface bandwdth both in terms of the signal rate and mac-rate.
   - I think that having client interface bandwidth is required, and probably appropriate to define here under flexe client interface configuration.
   - Specifying the bandwidth in Gbps is probably sufficient, the signal rate can be inferred from the bandwidth.  Allowable values (10, 40, or m*25).
     [xbn] OK. 


(G) Operational values:
(G 1) draft-jiang defines flexe-phy-status:
   - I think that this is okay, although I question whether this would end up being a duplicate of information already available in a generic Ethernet Phy YANG model.
   - I propose that this is retained at this time.
     [xbn]OK.


[RW]


Thanks, Rob


  [xb2]After more discussion, we think the flexe-phy-status is duplicated, and it's better not considered here.


[RW2] Fine.  Again, my aim here is really just to get to a common starting position.  Then issues can be raised and discussed for points like this one to decide what is best.


Thanks,
Rob


(G 2) draft-jiang defines flexe-client-status:
   - I think that this is a duplicate of the status information that should be available under the clinet interface itself for all Ethernet interfaces