Re: [CCAMP] Discussion on Flex-E YANG model structure [was  RE:CCAMPDigest, Vol 139, Issue 5]

"Rob Wilton (rwilton)" <rwilton@cisco.com> Wed, 08 January 2020 14:23 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 2442D12004C for <ccamp@ietfa.amsl.com>; Wed, 8 Jan 2020 06:23:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.519
X-Spam-Level:
X-Spam-Status: No, score=-14.519 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=WCQdq5kL; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=JzbpeeDv
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 L4-S6q0zhOPp for <ccamp@ietfa.amsl.com>; Wed, 8 Jan 2020 06:23:39 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA21D120044 for <ccamp@ietf.org>; Wed, 8 Jan 2020 06:23:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=52902; q=dns/txt; s=iport; t=1578493418; x=1579703018; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=K0ncWT+iRznlBRtXFLc4Yui82IAF9Sl+YIY2YYdU9WY=; b=WCQdq5kLFAuNsTJl3Y6bd5XG9WuzMJLPe/uO1pAyl+dEgx4zWPo/7ZtT V8HsUFw9/Xt0UrckhNjsknoniYbspHCelUIlPQ5mPd72BVju2N1M7eAHQ XlFLDoBJzuHelXyRBMAwpDxvu3x5uihJbsXz2ytK3sO8RY84BkA4pRJ+h s=;
IronPort-PHdr: =?us-ascii?q?9a23=3A7qbs+hMG2SWq1Z/ZcGMl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu60/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBjhM//ucys8NM9DT1RiuXq8NBsdFQ=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D3CQBW5RVe/5FdJa1mHgELHIMhL1A?= =?us-ascii?q?FbBNFIAQLKgqDf4NGA4sFgl+YDYFCgRADVAkBAQEMAQEtAgEBhEACF4FTJDg?= =?us-ascii?q?TAgMNAQEEAQEBAgEFBG2FCwYmDIVeAQEBAQMSEQoTAQElCwcBDwIBCBEBAwE?= =?us-ascii?q?BIQEGAwICAjAUAwMDCAIEAQ0FCBqDAYF5TQMuAQKgZwKBOIhhdYEygn4BAQW?= =?us-ascii?q?FCRiCDAmBNowZGoFBP4ERR4IeLj6EFgESASE0gloygiyNUQGCdIVXJIlBjyk?= =?us-ascii?q?KgjaWPIJHh36BA48Zg0eLDJpoAgQCBAUCDgEBBYFpImdxcBU7gmxQGA2DDIo?= =?us-ascii?q?GDBcVgzuKU3SBKI0ODxcHgQQBMF8BAQ?=
X-IronPort-AV: E=Sophos;i="5.69,410,1571702400"; d="scan'208,217";a="691494047"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Jan 2020 14:23:37 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 008ENbef026187 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 8 Jan 2020 14:23:37 GMT
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 8 Jan 2020 08:23:36 -0600
Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 8 Jan 2020 09:23:35 -0500
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 8 Jan 2020 08:23:35 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hWegGFseGa5Jxuvnbcz+4rP1sZjSsKOSdhl4pClBkjgaQnLlIopiL4I/5thmIrdxw5OI/QkNuo6huMB89bfumVRWS2gYT0OEjfVuhnA24ECM1CsteIhzkUs1FZPt0XLEcWceplgcYVmY+KCpLGqXRkXA8ZP0Uu5zagtLGMmfPH/V5j18UjyktXGsWgS+IeLk4tuATCw5fdG8oIySoO7UTpez70b/+aNCTOuSxc7IPcNIKTA5w8Uw57yIDkdfZkfYmxMhQEusq13/S+9sqm16Q/J//q5s2iAKBxz0r0vxN2xjB3fXbGb8gvfLB4l7xfb01FN/ZtUjOcSsGTH+Hf+CJQ==
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=K0ncWT+iRznlBRtXFLc4Yui82IAF9Sl+YIY2YYdU9WY=; b=M5xBZ2iEuysgYpoeMk7jz/Tvl8DKQ481y83T5Gv9Ksl0rYmxY2+1mmnT4kuGYvTv9R+DqhbCousGF7VP6SYupka0VzcLscPmkJDTzn2WwjvXqZq7M2BkU035YHydzX5REBMqzLLlCcSMS6oOLKGhCRhq+tgA8XjOzlURVz4Z9LB/JKS2ZCsNaSGcWClXtfeaOCmbNSBoj2W4krcZG+YhKtArcJZcMAhmCcJfJXiXWADyVXo+KVbCKDa9PyRns7A7WTKGRWZJ4avdcX6OZ2sdHDRYC2QwFl92q/OFxBL7FyfeL6mzl3lLBbBevtzXkljNiw8ev7yIdQiKkIOOKSHvxQ==
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=K0ncWT+iRznlBRtXFLc4Yui82IAF9Sl+YIY2YYdU9WY=; b=JzbpeeDvxGZPXEFRyQCdUdAOnpAf3Y45jYvv69m/M7o6jBx+sgFTVIcizBg4psjoRhdgvHE1zjhjGjIqhGygNlilK7VGw81nEVVuzlJBZK8/7kGG6ZbKuZ4MqTkP1tO7kbSz/XmEqzrHa5jHWbQUhmEFZBK0arkWe7/eFEQTOBQ=
Received: from MN2PR11MB4366.namprd11.prod.outlook.com (52.135.38.209) by MN2PR11MB3598.namprd11.prod.outlook.com (20.178.252.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.10; Wed, 8 Jan 2020 14:23:34 +0000
Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::b9ce:1058:5fa6:44a1]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::b9ce:1058:5fa6:44a1%7]) with mapi id 15.20.2623.008; Wed, 8 Jan 2020 14:23:34 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: Jiangyuanlong <jiangyuanlong@huawei.com>, "niu.xiaobing@zte.com.cn" <niu.xiaobing@zte.com.cn>
CC: "ccamp@ietf.org" <ccamp@ietf.org>
Thread-Topic: =?utf-8?B?W0NDQU1QXSAgRGlzY3Vzc2lvbiBvbiBGbGV4LUUgWUFORyBtb2RlbCBzdHJ1?= =?utf-8?B?Y3R1cmUgW3dhcyDCoFJFOkNDQU1QRGlnZXN0LCBWb2wgMTM5LCBJc3N1ZSA1?= =?utf-8?Q?]?=
Thread-Index: AQHVwiHAhYPm4supIEC1a0DEsx4a2Kfc62iAgACLuiCAA0XtAIAAFJUA
Date: Wed, 8 Jan 2020 14:23:33 +0000
Message-ID: <MN2PR11MB436645D8C8C0D21B894686CEB53E0@MN2PR11MB4366.namprd11.prod.outlook.com>
References: mailman.206.1577157479.6898.ccamp@ietf.org <202001031836012280585@zte.com.cn> <3B0A1BED22CAD649A1B3E97BE5DDD68BD382DAEF@dggeml532-mbs.china.huawei.com> <MN2PR11MB4366BA114707B2A9BC2EDB6CB53C0@MN2PR11MB4366.namprd11.prod.outlook.com> <3B0A1BED22CAD649A1B3E97BE5DDD68BD3839509@dggeml532-mbs.china.huawei.com>
In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68BD3839509@dggeml532-mbs.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.52]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 19230f0c-79cc-49f3-9ed9-08d794465809
x-ms-traffictypediagnostic: MN2PR11MB3598:
x-microsoft-antispam-prvs: <MN2PR11MB35982C43486FE554E75C4968B53E0@MN2PR11MB3598.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 02760F0D1C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(136003)(366004)(39860400002)(376002)(189003)(51444003)(199004)(10533003)(66476007)(478600001)(66446008)(66556008)(33656002)(6506007)(53546011)(66946007)(71200400001)(26005)(4326008)(186003)(110136005)(64756008)(76116006)(316002)(5660300002)(52536014)(7696005)(9326002)(55016002)(86362001)(81156014)(9686003)(81166006)(2906002)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3598; H:MN2PR11MB4366.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: yRIe8SgZmoVk3VyBWp4Gu4bZjL7kYcdugfn6KcTFIpEc6SI7LUzqjyJCxeR/+LwtNsQryc7QCB4HTaE5bbAToabH7t8y1ULZbtgDQM48YpGYGCC/SgUgJSXH/W4kRavTfAypwAgrlSOMK1oEZgzH5KN87uWFRRRF/7N57GKQ2IICsvghPeJoPuahb8+NEMWPg4v4iU/amPSFEWC6f1Fa+AORwk5oxVEmhC56eiwgVeeMQb/q5lYlwE2YEe92DTfQt55imJd/Y4vTSZEnwv58qgm10jsIsTeiwdZi8kAPCILDS83A0F3Dmb7ES8JDBWnMveShxAyiIHaPMmPnI617hbZg0NGghRCcTw7dUcy+Sik/EuY2ee/4XWccPPqzmwF7BZxJq/FGJIpqyCDbPEav/zRrExCMkGM0LrAW9RIJ5UlQRQ4T/T2WncaXL6ZcwqPDkRk+MqJ/1nKUhFjaV/JskXFbbBtjcChFcDblVNvX2WVIV07PKivCh60FNAgRHlehB5eYYVXCGAmusxFAuObIgQ==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR11MB436645D8C8C0D21B894686CEB53E0MN2PR11MB4366namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 19230f0c-79cc-49f3-9ed9-08d794465809
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2020 14:23:34.0202 (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: g7x2CDh1y3HC6Axu5K73/dYfBceLjYXj7n8xMfi7q8YgAAlATUPm8N8HQL3NOM9s2/K+XtAqSZ3XTWPKHSsPQw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3598
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com
X-Outbound-Node: rcdn-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/tYgAHN5nbuhtyhKsG5Od0mP4OGk>
Subject: Re: [CCAMP] =?utf-8?q?Discussion_on_Flex-E_YANG_model_structure_=5Bw?= =?utf-8?q?as_=C2=A0RE=3ACCAMPDigest=2C_Vol_139=2C_Issue_5=5D?=
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: Wed, 08 Jan 2020 14:23:42 -0000

Hi Yuanlong,

I think that it is a question of what is expected when the configuration is validated:
  E.g. (1) does the device allow a management agent to configure a FlexE client interface under the /interfaces/interface list without a corresponding entry under the FlexE group client interfaces?
          (2) does the device allow a management agent to configure a FlexE client interface under a FlexE group without a corresponding entry under the /interfaces/interface/ list?

I think that doing (2) is fine (as per my previous email).  But my questioning was really whether (1) should be allowed or not, but most importantly whatever is decided, it would be good to document the expected behavior.

Thanks,
Rob



From: Jiangyuanlong <jiangyuanlong@huawei.com>
Sent: 08 January 2020 12:39
To: Rob Wilton (rwilton) <rwilton@cisco.com>om>; niu.xiaobing@zte.com.cn
Cc: ccamp@ietf.org
Subject: RE: [CCAMP] Discussion on Flex-E YANG model structure [was  RE:CCAMPDigest, Vol 139, Issue 5]

Robert,

Thanks for your in-depth comments. I think they touched an important issue, that is the instantiation relationship between a FlexE Group interface (including FlexE client list as a container) and the actual client interfaces (each interface is referenced by an if:interface-ref in our models).
My opinion is,  the creation of a FlexE Group interface and the creation of client interfaces are decoupled processes, as interface-ref only needs to reference to an interface name. Thus all options can be supported.
Or did I miss something?

Best regards,
Yuanlong

From: Rob Wilton (rwilton) [mailto:rwilton@cisco.com]
Sent: Monday, January 06, 2020 8:19 PM
To: Jiangyuanlong <jiangyuanlong@huawei.com<mailto:jiangyuanlong@huawei.com>>; niu.xiaobing@zte.com.cn<mailto:niu.xiaobing@zte.com.cn>
Cc: ccamp@ietf.org<mailto:ccamp@ietf.org>
Subject: RE: [CCAMP] Discussion on Flex-E YANG model structure [was  RE:CCAMPDigest, Vol 139, Issue 5]

Please see [RW] inline for my comments:

From: CCAMP <ccamp-bounces@ietf.org<mailto:ccamp-bounces@ietf.org>> On Behalf Of Jiangyuanlong
Sent: 06 January 2020 02:20
To: niu.xiaobing@zte.com.cn<mailto:niu.xiaobing@zte.com.cn>
Cc: ccamp@ietf.org<mailto:ccamp@ietf.org>
Subject: Re: [CCAMP] Discussion on Flex-E YANG model structure [was  RE:CCAMPDigest, Vol 139, Issue 5]

Xiaobing,

Please see my comments inline.

Thanks,
Yuanlong

From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of niu.xiaobing@zte.com.cn<mailto:niu.xiaobing@zte.com.cn>
Sent: Friday, January 03, 2020 6:36 PM
To: ccamp-request@ietf.org<mailto:ccamp-request@ietf.org>
Cc: ccamp@ietf.org<mailto:ccamp@ietf.org>
Subject: Re: [CCAMP] Discussion on Flex-E YANG model structure [was  RE:CCAMPDigest, Vol 139, Issue 5]


hi,  yuanlong

Please refer to comments entitled with [Xiaobing]



On the contrary, the description in Section 5 of OIF FlexE 2.0 is more specific: "The FlexE Shim is the layer that maps or demaps the FlexE Clients carried over a FlexE Group" and "Each FlexE Client has its own separate MAC, Reconciliation Sublayer, and xMII above the FlexE Shim which operate at the FlexE Client rate." The relationship of a FlexE Client, FlexE Shim and its FlexE Group is rather fixed according to this description.

[Xiaobing] In my opinion, those descriptions exactly support the flexibility between FlexE clients and a FlexE group.

[Jiang] Yes, it should be flexible, but not in the way “they (FlexE Clients) can stand alone before configured to a FlexE group”.

In Rob’s YANG module, the modeling of “client-interface” (similar to flexe-client-list in draft-jiang) actually has an attribute “name if:interface-ref”, which can reference to any internal interface (as described in 7.2.1, unclear what parameter is to be managed yet) or any Ethernet PHY (as described in 7.2.2).

Therefore, it provides the flexibility to support any type of FlexE Client bit-stream (i.e., 64B/66B encoded bit-stream).



Otherwise, if FlexE Client is modeled as standalone and could be associated with different FlexE Groups (assuming there is such a support in the data plane), we can hardly configure anything when its FlexE Group is undetermined, since:

[Xiaobing] The configuration of a FlexE client and group can be performed at different time. Just image you first establish a FlexE group without carry any FlexE client, and then configure some FlexE clients over that group.

[Jiang] Totally agreed that we can create a FlexE Group first, and then configure FlexE Clients over that group. My point was “not to create FlexE Clients first, and then associate with a FlexE Group”.

[RW]

I also completely agree that FlexE groups can be configured first, and then Flex-E client interfaces can be subsequently created, deleted, or have their bandwidth modified after the group exists.  I think that this is one of the core concepts of the flexible ethernet architecture.

In terms of creating client interfaces without flex-e groups, that isn’t so obvious to me.  A flex-e client interface has two key parts of configuration:

(i)               A client interface entry under a Flex-e group.  I see that this list entry is the trigger that forces the creation of a flex-e client interface in the system.

(ii)             An interface entry under /interfaces/interface.  I see that this is really the container for all configuration associated with a flex-e client interface, but doesn’t cause its existence.

As I see it, there are four choices as to how to handle this co-dependent configuration:

  1.  Require both the /interfaces/interface list entry to exist and the /flex-e/group/client-interface list entry to exist
  2.  Allow the /interfaces/interface list entry to be optional when the /flex-e/group/client-interface list entry exists
  3.  Allow the /flex-e/group/client-interface list entry to be optional when the /interfaces/interface list entry exists
  4.  Allow both list entries to be optional, i.e. either can exist without the other

Also considering the NDMA architecture (RFC 8342), there is a logical split between what exists in configuration (i.e. intended/running datastores) vs what exists operationally in the system and is reflected in the operational datastore.

For me, I think that option (2) represents the cleanest model:

  *   the existence of /flex-e/group/client-interface is the trigger for creating the client interface, and when that configuration is applied in the system, then I would expect the corresponding client interface to exist in the system and be represented by an entry in /interfaces/interface in the operational datastore.
  *   an entry for the client interface only has to exist in /interfaces/interface in the running datastore if some interface configuration has been provided by the operator.

However, I also think that it may be okay to allow some flexibility if a client configures an entry in /interfaces/interface without a corresponding entry in the /flex-e/group/client-interface list:

  *   some devices may reject this configuration as being invalid
  *   other devices could allow this configuration to be accepted into the running configuration datastore, but not create the interface in operational.  I.e. this is handled equivalently to a missing linecard (as per section 5.3.2 of RFC 8342).

But whatever is decided by the WG, it would be good to document the expected behavior in the model.

Thanks,
Rob



BR

Xiaobing Niu