Re: [CCAMP] Thoughts on Flex-E YANG models

"Rob Wilton (rwilton)" <rwilton@cisco.com> Tue, 26 November 2019 11:24 UTC

Return-Path: <rwilton@cisco.com>
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 4F42D12089A for <ccamp@ietfa.amsl.com>; Tue, 26 Nov 2019 03:24:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=eFsBGqqA; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=kceXWUiP
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 8g_OJIFyhT9n for <ccamp@ietfa.amsl.com>; Tue, 26 Nov 2019 03:24:10 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56ECC12088F for <ccamp@ietf.org>; Tue, 26 Nov 2019 03:24:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=59638; q=dns/txt; s=iport; t=1574767450; x=1575977050; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=EnOohaSteT7ueAqziHIVlzp5iOm6ytrKkqzeLmKf+gY=; b=eFsBGqqAXpHzZeBwReXntVRWRNGCocfLA7HFbUp9RdcvhWAdrp7Be4bg qkBIE+tuomdHwP2U9RjcrE7j6VPG33SMp9vS8fHvWnQD0X/BCq7Krcvkd helyCzkZoIgJa+b3JfSPX1YqOB+6ptlnjs4/fiSOWWgbmznpWvRPzjLw5 U=;
IronPort-PHdr: =?us-ascii?q?9a23=3AK2Y1shfrNwV8P9HdZARa7X2WlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwGRD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/dTM7GNhFUndu/mqwNg5eH8OtL1A=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CCAAA7Ct1d/4cNJK1bChoBAQEBAQE?= =?us-ascii?q?BAQEDAQEBAREBAQECAgEBAQGBbQIBAQEBCwGBGy8kBScFbFggBAsqCodnA4p?= =?us-ascii?q?vToIRmASBQoEQA1QJAQEBDAEBIwoCAQGEQAKBdSQ3Bg4CAw0BAQQBAQECAQU?= =?us-ascii?q?EbYU3DIVSAQEBAQMSCBMTAQEwCA8CAQgRBAEBIQEGBzIUCQgBAQQBEggXA4M?= =?us-ascii?q?BgXlNAy4BAgynIwKBOIhggieCfgEBBYUYGIIXAwaBNgGMFRqBQD+BEEiCTD6?= =?us-ascii?q?CZAKBMAEHCwEhJAcJgwyCLI1eiAMkmDMKgiyHHY5Ugj+HaoQ+izaOSIg8kVY?= =?us-ascii?q?CBAIEBQIOAQEFgWgjKj1xcBU7gmxQERSGSIEnAQKCSYpTdIEojAeBIgGBDgE?= =?us-ascii?q?B?=
X-IronPort-AV: E=Sophos;i="5.69,245,1571702400"; d="scan'208,217";a="444655344"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Nov 2019 11:24:05 +0000
Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id xAQBO4jb021842 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Nov 2019 11:24:04 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 26 Nov 2019 05:24:03 -0600
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 26 Nov 2019 05:24:03 -0600
Received: from NAM04-BN3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 26 Nov 2019 06:24:03 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WzY1KagrgHMLqyX9ovC5TS4OAGng0aBFR3qDZiqFJ+IMUytXjYVc4BJJg8qeqcThyarFxjFJ5/0D48aKf78cWzkdubEyOnVOwNoFfwTdz0uJs3uOFAZn8flT7VwXVgdv+fXobsLB23jS4quGV0oTElafiBaC0FYBLjIhGn/hIRPlbBnoVHLZpCpeEU4IZWk+oV00ZTijD7ba6lioqTwtO0v7DL2RSmSvkGHFAJu/xfoimnPKUTKEgA+D8TapFEIhCva2RunAwyzObYSr0sGwdL4Gg9HoRE3UxPwsRWJDPw4uzRtG71ny03N8hYKhAqHU63sT6s6xEV+4/M+zl/hDZg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VNlbZZEhO9s9WRnPDcVWUCjP2Iwra4eKIn8bQsFTa0Y=; b=gXgv7+7iVy9ibw07F47f48SZX659VKlgXpHfIaxNo8vKBjr5lEeaLpxLD9iJDW5BdW2u1FqRm1GHsgGW/kY2ZKu5wWU4ecNNrCvUPHAuodWQlksz1CA89Iu//YNNIY1HfWSm9raUQfsHNfR9RtsSmpSwV+uknU5aUeXm88Iwl6V2RF20eEdVLAf3zzXpwVFXWJTFI7kW8LsuDWMbQIpV8o0R0UNQQFAgLPXoaVHWF0A9S6icUru418CffhvPsuYofzvlT+fIGB2vds9BO5xAfifuG81cNcLKv/ypZ5GlHq42xFVqsXemA2NX5vIrQkEAN4U+jef/PxiKdZB48EOuig==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VNlbZZEhO9s9WRnPDcVWUCjP2Iwra4eKIn8bQsFTa0Y=; b=kceXWUiPUHWte+YsWkPb92Uto2n3TV2S+NgibG5Zs8ZjAz72RvWb7+Ld8YVMyfVgVLMVYizWkn2dKR7PDKx0wZSy0BcYQrIRuPYF132XxoIDQj0QK2AIIJj+cfMgPm8Wvw8y0OOb7LOb3HNAM5CpefRC4vsUtNL9BcxgFRbXGhE=
Received: from MN2PR11MB4366.namprd11.prod.outlook.com (52.135.38.209) by MN2PR11MB3838.namprd11.prod.outlook.com (20.178.252.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.23; Tue, 26 Nov 2019 11:24:02 +0000
Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::49b6:bc5c:bd3e:203c]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::49b6:bc5c:bd3e:203c%5]) with mapi id 15.20.2474.023; Tue, 26 Nov 2019 11:24:02 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: Jiangyuanlong <jiangyuanlong@huawei.com>, "ccamp@ietf.org" <ccamp@ietf.org>
Thread-Topic: Thoughts on Flex-E YANG models
Thread-Index: AdWhDyWGrnTE6LENT0aWnLFB03XMUACLAReQABIq+LAAHwXQgAASASLA
Date: Tue, 26 Nov 2019 11:24:01 +0000
Message-ID: <MN2PR11MB436634750531F1B712A30DADB5450@MN2PR11MB4366.namprd11.prod.outlook.com>
References: <MN2PR11MB436635770A169EACDD7E0F54B5490@MN2PR11MB4366.namprd11.prod.outlook.com> <3B0A1BED22CAD649A1B3E97BE5DDD68BD37A49E8@dggeml512-mbx.china.huawei.com> <MN2PR11MB4366E60D5F35F5E98CA63C07B54A0@MN2PR11MB4366.namprd11.prod.outlook.com> <3B0A1BED22CAD649A1B3E97BE5DDD68BD37ACE74@dggeml512-mbx.china.huawei.com>
In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68BD37ACE74@dggeml512-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rwilton@cisco.com;
x-originating-ip: [173.38.220.57]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 558e7b82-de6e-41b4-91ab-08d772632393
x-ms-traffictypediagnostic: MN2PR11MB3838:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <MN2PR11MB3838457577C4613DF72D2960B5450@MN2PR11MB3838.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0233768B38
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(39860400002)(396003)(366004)(136003)(199004)(189003)(51444003)(52314003)(81166006)(606006)(102836004)(66476007)(229853002)(66556008)(64756008)(66446008)(8936002)(25786009)(81156014)(3846002)(66946007)(6246003)(478600001)(186003)(6436002)(6306002)(55016002)(8676002)(86362001)(71200400001)(7736002)(71190400001)(236005)(26005)(9686003)(74316002)(30864003)(5660300002)(6506007)(53546011)(76116006)(54896002)(66066001)(7696005)(316002)(52536014)(76176011)(446003)(2906002)(11346002)(966005)(33656002)(6116002)(790700001)(2501003)(14454004)(110136005)(99286004)(256004)(170073001)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3838; H:MN2PR11MB4366.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: gpIWzcfnKHR2Xg3WnxuksXcGh/XZIF8or0dhwusR+n7z8Pvq+q78iCgq015D+/Xue5NK9R/I15N3f5K6EIPX9Cxe81obhtvR7wicPLVW8ZpOZseZC5xCqz2jAu59ywD6hYg2M48UEgDOExwnZgoElNc2WhdPCj5HWHHDSr/DmLpXUofc+0h6NHFNtG6upHHGuPUYzIaY2k7oDTZdAz39rqYoIohUaebDw5vk4wkEVu9paww17MH6iz6ZgRrdmZOCW3U8gQF3pcGTc/KBMi6ua1dv5AzerJ/avNNnPmn62g8g0/v8+iqJdMK7prPx6cGr5MSv6loDh4+Elo2Zlevy1HuqolXIcZDiYdw6FRKNQ4IcTUF7szbMV3PB7ac24P98pBM19M/gxI+UQxl6ae18mtulN4jg8SU8zEF66AkDm2qmT0+h2ck71dB0JtFVQ9zoA11vqJ01qCD8bkv5PGrd/8A0ZX6huNKmN6gHtzInMO4=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR11MB436634750531F1B712A30DADB5450MN2PR11MB4366namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 558e7b82-de6e-41b4-91ab-08d772632393
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Nov 2019 11:24:01.9807 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: E9BhIHoess4VS2CLZWuY59msJyMDEzotS4/cBakgdaxGd39ihpz4X/4FAJLy06dkMGawaN5Us6ZDAVHKNnDiAg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3838
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.18, xch-rcd-008.cisco.com
X-Outbound-Node: alln-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/nTCeucLH2n-H-pb3Pz4gvIq49VU>
Subject: Re: [CCAMP] Thoughts on Flex-E YANG models
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: Tue, 26 Nov 2019 11:24:13 -0000

Sorry, I accidentally hit send on my last email before typing anything!

Please see some further comments [RW] inline ...

From: Jiangyuanlong <jiangyuanlong@huawei.com>
Sent: 26 November 2019 03:05
To: Rob Wilton (rwilton) <rwilton@cisco.com>om>; ccamp@ietf.org
Subject: RE: Thoughts on Flex-E YANG models

Rob,

I believe we are quite aligned in the abstract structure of the FlexE model.
Please see my further comments inline prefixed with [Jiang1].

Thanks again,
Yuanlong

From: Rob Wilton (rwilton) [mailto:rwilton@cisco.com]
Sent: Monday, November 25, 2019 11:40 PM
To: Jiangyuanlong <jiangyuanlong@huawei.com<mailto:jiangyuanlong@huawei.com>>; ccamp@ietf.org<mailto:ccamp@ietf.org>
Subject: RE: Thoughts on Flex-E YANG models

Hi Yuanlong,

Please see [RW] comments inline ...

From: Jiangyuanlong <jiangyuanlong@huawei.com<mailto:jiangyuanlong@huawei.com>>
Sent: 25 November 2019 03:54
To: Rob Wilton (rwilton) <rwilton@cisco.com<mailto:rwilton@cisco.com>>; ccamp@ietf.org<mailto:ccamp@ietf.org>
Subject: RE: Thoughts on Flex-E YANG models

Hi Rob,

Thank you  a lot for your comments, they are very helpful.
Please see my further comments inline.

Cheers,
Yuanlong

From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Rob Wilton (rwilton)
Sent: Friday, November 22, 2019 11:01 PM
To: ccamp@ietf.org<mailto:ccamp@ietf.org>
Subject: [CCAMP] Thoughts on Flex-E YANG models

Hi,

I have some general thoughts on modelling Flex-E in YANG that may help the authors converge.  These comments mostly relate to what I would call the overall shape of the YANG model rather specific configuration (which I think can probably be sorted out once the shape has been agreed).

1.      Flex-E groups should be identified by their group-number (both models seem to do this, but the group number seems to be optional in one model)
2.      The configuration to identify the bonded phys should be under the flex-e group (both models do this).
[Jiang] Agreed to both.

3.      In the flex-e group's bonded-phy interface configuration list, bonded-phy interface list entries could be keyed either by the bonded phy interface name, or the flex-e phy number.
a.      I would suggest that the bonded-phy interface name is the more meaningful identifier to clients.
[Jiang] Just to be clear, are your saying that the list of flexe-phy should be keyed by the interface name? I think in our model, current key "flexe-phy-if" is exactly the PHY interface name, as shown in RFC 8343:
"     typedef interface-ref {
       type leafref {
         path "/if:interfaces/if:interface/if:name";
"
[RW]
Yes.

b.      Either way, the entries should also indicate the binding to the bonded-phy interface (e.g. by an interface-ref - both models seem to do this).
4.      The configuration required to define the client interfaces associated with a flex-e group should be under the flex-e group list entry, based on the assumption that that 16 bit client id must be unique within the group rather than across groups.
[Jiang] Totally agreed.

5.      In the flex-e group's client interface configuration list, client interface list entries could be keyed either by the client interface name, or the client id.
a.      Again, I would suggest that using the client interface name is the more meaningful identifier for clients.
[Jiang] Earlier we already planned to use "flexe-client-if" as the key to flexe-client-list. Could this resolve your comment?
[RW]
Yes, I think so.  It would be an interface-ref, similar to bonded-phy interface-ref.

However, I think that there is probably a slight difference in semantics:

In the case of the interface-ref for bonded phys, semantically it should probably be "require-instance true" (which is the default behaviour).  I.e. for the flex group configuration to be valid, it makes sense for the referenced bonded-phy interfaces to also exist in the configuration.

But in the case of the interface-ref for client interfaces, I think that it should be "require-instance false".  This is because the flex-e client interface configuration defines the parameters to create the client interface but should not require that the client interface to exist in the configuration at the same time (even if that may often be the case).

[Jiang1] Agreed. My colleague Italo also expressed such an opinion during ITU-T Q14/SG15 interim meeting not long ago.

b.      Either way, the entries should also indicate the binding to the client interface (by interface-ref - both models seem to do this).
6.      Client interfaces should be modelled as regular interfaces, and use the normal iftype for Ethernet interfaces, i.e. the dubiously named iftype:ethernetCsmacd.  Without using this type regular Ethernet YANG configuration (e.g. as defined in 802.3.2) won't work properly.
a.      I don't think that there should be flex-e specific configuration under the client interface itself, instead, the flex-e specific configuration should be defined as part of the group + client interfaces.
[Jiang] Agreed to bullet a). But I have some doubts whether we can use the normal iftype for Ethernet interfaces directly. As FlexE Client includes only a thin MAC layer, while PHY layer is decoupled into the FlexE PHY, FlexE client management should be simpler than the regular Ethernet YANG configuration, furthermore, it seems to me all the YANG models defined in 802.3 or 802.2 more or less include some PHY configuration which cannot be applied to a FlexE client. Nevertheless, we look forward to seeing more discussions on this topic.
[RW]
>From the rest of the system perspective, a client interface really should look/feel like a regular physical Ethernet interface, and I think that the majority of the 802.3.2 configuration/statistics should apply.  Auto-neg, duplex, speed shouldn't be configurable, but then they can't be configured on most higher speed optical interfaces anyway.  I would have thought that the rest of the module should apply (otherwise this Ethernet configuration would need to be duplicated in another module, which isn't ideal).
[Jiang1] If a reference model can work, that will be better for sure.

But I think that the main issue to resolve is whether Flex-E group configuration is global or scoped to a FlexE group interface..  I can see pros and cons both ways:
1.      Putting the configuration under an FlexE group interface seems like a slightly artificial construct.
2.      However, this does mirror how LAG interfaces are represented (at least in our vendor model), and in some ways FlexE interfaces could be considered to be like an L1 LAG interface.  However, in the LAG case, the LAG interface can forward traffic, where as for FlexE groups, this would not be the case.
3.      There is probably a natural binding between a FlexE group and the client interfaces that closely relates to the parent child relationship between an interface and sub-interface.  E.g. disabling a FlexE group should have the effect of disabling each FlexE client interface.
4.      My overall feeling is that representing the FlexE groups as a type of interface seems like a reasonable configuration model.
[Jiang] Totally agreed.
[RW]
Note, I have made an assumption here that it is reasonable to represent the L1 layer of an interface as an entry in if:interfaces/if:interface.  It is worth noting that not all configuration/state in ietf-interfaces would apply sensibly to an L1 interface representation.  In particular, none of the statistics would seem to apply to the physical layer.
[Jiang1] That is true indeed.

Anyway, hopefully these comments are useful to help the two sets of authors converge towards a common model.  I have other suggestions on the specific models but would suggest solving the big picture issues first.
[Jiang] Very useful indeed, we look forward to your further suggestions on the models.
[RW]
Thanks.  It would also be useful to see comments from other members of the WG, in particular, the authors of the draft-xiaobn-ccamp-flexe-yang-mod-03.

[Jiang1] Yes, we also hope to see more inputs from the WG.
In case it helps, here is the pyang tree output of the structure that I believe is most suitable to represent Flex-E interfaces:

module: ietf-if-flex-e
  augment /if:interfaces/if:interface:
    +--rw flex-e
       +--rw group
          +--rw group-number              uint32
          +--rw more-group-config-here?   string
          +--rw bonded-phy* [name]
          |  +--rw name                           if:interface-ref
          |  +--rw phy-number?                    uint8
          |  +--rw more-bonded-phy-config-here?   string
          +--rw client-interface* [name]
             +--rw name                              if:interface-ref
             +--rw id?                               uint16
             +--rw more-flex-e-client-config-here?   String


[Jiang1] Not sure we need both "flex-e" and "group" the same time (a little redundant in the structure IMO), otherwise I believe we are fully aligned in the overall structure.

[RW]
So this is a relatively minor point, and I could go either way on this.

>From my perspective it is 'nice' from a modelling perspective if the configuration for a particular feature is under a single container:

  *   It makes it easier to either just get that configuration, or to filter it out if it is not wanted.
  *   It is easier for clients to immediately relate the configuration back to a particular feature/protocol.

E.g., if it is plausible that there is any need for any device-global flex-e configuration, then I would propose putting that under a single top-level flex-e container.

Equally, if there could ever be flex-e configuration on a flex-e-group interface that isn't specific to the group then having the extra layer in the hierarchy is cleaner.  However, that this seems unlikely in this case, given that the interface represents a flex-e group ...

Another choice could be to only have a single layer of hierarchy, but call the top level container "flex-e" rather than "flex-e-group", e.g. :

module: ietf-if-flex-e
  augment /if:interfaces/if:interface:
    +--rw flex-e
       +--rw group-number              uint32
       +--rw more-group-config-here?   string
       +--rw bonded-phy* [name]
       |  +--rw name                           if:interface-ref
       |  +--rw phy-number?                    uint8
       |  +--rw more-bonded-phy-config-here?   string
       +--rw client-interface* [name]
          +--rw name                              if:interface-ref
          +--rw id?                               uint16
          +--rw more-flex-e-client-config-here?   string




I don't know whether phy-number and id should be mandatory.  I.e. always defined, or whether it is feasible that these could be automatically allocated by the device.

[Jiang1] phy-number and client id are mandatory. They can be configured in most use cases, but for static configuration as described in FlexE IA, they can be fixed (i.e., determined by the device), that means, they may be read-only.

[RW]
Okay, so from a YANG perspective, I think that makes them "mandatory false", since they don't have to be configured.  The description statements should make it clear that these fields must be provided in the operational datastore.

Thanks,
Rob

Of course, I have excluded any specific configuration options.  I would suggest trying to get agreement on the overall structure (i.e. the shape of the YANG model) first.

The YANG model that this is built from is available at: https://github.com/rgwilton/flex-e-yang/blob/master/ietf-if-flex-e.yang

Regards,
Rob


Regards,
Rob