[CCAMP] Thoughts on Flex-E YANG models

"Rob Wilton (rwilton)" <rwilton@cisco.com> Fri, 22 November 2019 15:01 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 DC69812083C for <ccamp@ietfa.amsl.com>; Fri, 22 Nov 2019 07:01:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 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, 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=Sx0ECyjU; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=NeGyTyjP
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 T8X-VRzRb0k6 for <ccamp@ietfa.amsl.com>; Fri, 22 Nov 2019 07:01:08 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B046D1200DB for <ccamp@ietf.org>; Fri, 22 Nov 2019 07:01:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14883; q=dns/txt; s=iport; t=1574434868; x=1575644468; h=from:to:subject:date:message-id:mime-version; bh=anSDL2owzwkPWZYtFBCCpqmkFYWfmFH0WeUAqJVNzhg=; b=Sx0ECyjUTDwuI76MFf1IKJuK4dG7TW/TY4xbb4LdIRPiEOPYJauqZwpb /whjbUrPnLKGIfH9w3iCzcdFT8pU6mGjhegClY6cGxrLsZHNmQ72rkbED SC4LGCiCBtu1qwIwOgHUHVKC/5viRN3PmH0/TQ7EXbCPMBYAP9N2fj5eB g=;
IronPort-PHdr: 9a23:eIX32xSDhzlzHQ9PoQASzV3Lo9psv++ubAcI9poqja5Pea2//pPkeVbS/uhpkESXBdfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH15g640NmhA4RsuMCEn1NvnvOjYlHcBeU1lN9HCgOk8TE8H7NBXf
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BuFgD+99dd/4oNJK1bCh4BCxyBcwuBHC9QBWxYIAQLKgqHZgOKbE6VMIRiglIDVAkBAQEMAQEtAgEBhEACgiokNwYOAgMNAQEEAQEBAgEFBG2FNwELhWobEwEBMAgRAYEAJgEEGxcDgwGBeU0DLQEBAqQJAoE4iGCCJ4J+AQEFhQsYghcJgTaMFhqBQD+BV4ckLYNAgiyNXYgBJJgyCoIrA5VomhiOSJoMAgQCBAUCDgEBBYFoIyqBLnAVO4JsUBEUhkiDc4pTdIEojw4BgQ4BAQ
X-IronPort-AV: E=Sophos;i="5.69,230,1571702400"; d="scan'208,217";a="666211969"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Nov 2019 15:00:53 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id xAMF0qFc031339 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for <ccamp@ietf.org>; Fri, 22 Nov 2019 15:00:52 GMT
Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 22 Nov 2019 09:00:51 -0600
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 22 Nov 2019 09:00:51 -0600
Received: from NAM04-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 22 Nov 2019 09:00:51 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=D4AcozP9p3nBva6z/dKvGUtJaar3Fy8JRZtSccV1k2NmGWI3mzl5ibYSvZF7Wgz80wTWksEps2EVT1idYd4/uKBfOcL250gO0p9uJdmS9Jdh/JVP8qHNnWcdXtG3g2t0D0EsaMMHBp0Awtq7r8u/T3lrZhD2jR+yxOdCQ2qbvtAK+YWvabHjZm66Cfi9kVZCcI+3aWJFX6affUb5lZjo8DKPGbroviL6mALMZ35CRkihEcnN2EnzTYkiZE4Sjs+Y0uTWOHsztuOkzPZlgmUcTmClUpMPOSb727+Wg7CwpynPjPrnu/yUWtMABWl4q5PFQHfMJMbaC8kDwzRPOVpVxw==
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=6417eO9nyrtpL+BuuA10eZ9rQKftnClS/boubhxbudM=; b=FDyDjIMVc7D3bZUnhXE6dL73J4bXpam5qif4t+1/tXZkZYgwliAcCXw6bKoK+BCnNFyMB9gaKICZPqR/4nbgELnxJaLf01I2uAg1C0yd/aLdn60DyS6N9k7m3aLPwpPu8UoUrDjGZ9daEPBGvkI/L/7ihWXWL+AgQJQzqgL60SZuVzQ+PcNTBoVWMT74+YGGiUQ562h5Nb4vdE4Xr0wLDoeWE9bPVF5uwJcUDc8aJcxPeLUYI1OHZmu/LEEH2DxOg8MsUBvPGuBstWIdpqicAld1XD7A73E30VSsnoJ8IgrvLo8xCJkh19mj5cqcHjqeakn/mXXEOMsw7DiDz2di0w==
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=6417eO9nyrtpL+BuuA10eZ9rQKftnClS/boubhxbudM=; b=NeGyTyjPMs1UHTyO2drFWayXVF2g5hLbCTEkALKfjvh4enLbiAEAMXW8sbQDWitOFayDvbABRZWUXR5modFn4NfrkIPdjWv/s5Sn5GYfCJzZkwn3EvM9f+aI/tvPNW0U7CWLbiTSAjm9szIwifbxt01yFrxySp53rHvPSQgVzU0=
Received: from MN2PR11MB4366.namprd11.prod.outlook.com (52.135.38.209) by MN2PR11MB4158.namprd11.prod.outlook.com (10.255.181.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.19; Fri, 22 Nov 2019 15:00:50 +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.019; Fri, 22 Nov 2019 15:00:50 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: "ccamp@ietf.org" <ccamp@ietf.org>
Thread-Topic: Thoughts on Flex-E YANG models
Thread-Index: AdWhDyWGrnTE6LENT0aWnLFB03XMUA==
Date: Fri, 22 Nov 2019 15:00:50 +0000
Message-ID: <MN2PR11MB436635770A169EACDD7E0F54B5490@MN2PR11MB4366.namprd11.prod.outlook.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: [103.137.210.170]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7cdaead4-76ef-4475-17f4-08d76f5cc367
x-ms-traffictypediagnostic: MN2PR11MB4158:
x-microsoft-antispam-prvs: <MN2PR11MB4158B702939731920D48AA56B5490@MN2PR11MB4158.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 02296943FF
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(376002)(366004)(396003)(136003)(346002)(199004)(52314003)(189003)(51444003)(66946007)(74316002)(1730700003)(8676002)(9686003)(66556008)(54896002)(6306002)(66476007)(6916009)(76116006)(55016002)(186003)(8936002)(81156014)(81166006)(9326002)(86362001)(7696005)(102836004)(7736002)(6436002)(25786009)(5640700003)(64756008)(66446008)(2501003)(26005)(6506007)(33656002)(478600001)(2351001)(66066001)(3846002)(790700001)(6116002)(2906002)(99286004)(256004)(71200400001)(52536014)(5660300002)(71190400001)(14454004)(316002)(170073001); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4158; 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: am3+OKin3fBjYKbCUw+6iGYI4o2NpFOoz5wQfB79/sR2exZ7eh9coRG7V9+FYdPNEl1hp65GyTMdShvZn61NIhaSUTF2Z4mvGnAo+S5Y3p0H4Ajd1ggRjrscZVjJeex6wsiu2hGKGkmur8yH1atk9cHQXr6P1tN/ku93HjTxwQfhofTTVofZ+5TfeqkUuL9FpsV0YZ2k+xDlbsU3nwb49b0eyUBoe+Gntlqafi+nYyHWc2h2G5fRkIvQnhRbxHMOgWjAu5j+Zotk7t2Y7HlY71yLK5oQbNqbHYFC694/maZVAUZ+HIsxU9YuVIgCUnXVpnGaeOekH0KpgJv4zb1gYlkkNEo5p0mm8yDYhRKoBG5h/tVunjDgIPp3D8Pa4TNUkU+CSChk0pw4vXE9bEnsgnQWFaL4yctHog6INGN3E+801TDJ1i/j0RcPIej4hjb0
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR11MB436635770A169EACDD7E0F54B5490MN2PR11MB4366namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 7cdaead4-76ef-4475-17f4-08d76f5cc367
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Nov 2019 15:00:50.0713 (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: w0bnlNcXdOsi+R0LBGqHYhNjnoehNYfyZ+tzpncBWWVlHH2nqo6iK3hFzTPuzE4VERSmR6oOcoanfQbLUS+zGQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4158
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com
X-Outbound-Node: alln-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/G6ys4DCMsrfXeVRNlImvhMcK9jk>
Subject: [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: Fri, 22 Nov 2019 15:01:11 -0000

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).
  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.
     *   I would suggest that the bonded-phy interface name is the more meaningful identifier to clients.
     *   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.
  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.
     *   Again, I would suggest that using the client interface name is the more meaningful identifier for clients.
     *   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.
     *   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.

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.

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.

Regards,
Rob