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

"Rob Wilton (rwilton)" <rwilton@cisco.com> Mon, 06 January 2020 12:18 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 A28531207FC for <ccamp@ietfa.amsl.com>; Mon, 6 Jan 2020 04:18:52 -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=hOzcGNmT; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=c74sXUew
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 7ok4mBau2S65 for <ccamp@ietfa.amsl.com>; Mon, 6 Jan 2020 04:18:49 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88E2212025D for <ccamp@ietf.org>; Mon, 6 Jan 2020 04:18:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=42462; q=dns/txt; s=iport; t=1578313129; x=1579522729; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=92360DJvFc+QoZMw+E44UEke6MEQXvhA9YlqR7XAN+0=; b=hOzcGNmTL0U2EZIgccIG569j/IrPnxZm7QCL6VbU8ITYchoKsxJhLGff AXC23LbvAkN9T7jwqPoKLV6KtkdyzsG4ULtLk0nZ1WzeeJCNncyhuu2T+ HHD9HZg6rFpp3Jz4jvuMzF3/6G1qPCkHXqU+pzkgxTHrF2T8uw/1yXotv 4=;
IronPort-PHdr: =?us-ascii?q?9a23=3ADxQ2GBPwbkj1YaSf8vsl6mtXPHoupqn0MwgJ65?= =?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?A0DlCQC6JBNe/40NJK1mHgELHIMhL1A?= =?us-ascii?q?FbFggBAsqCoN/g0YDin+CX5gNglIDVAkBAQEMAQEtAgEBhEACF4FSJDgTAgM?= =?us-ascii?q?NAQEEAQEBAgEFBG2FCwYmDIVeAQEBAQMSEQoTAQElCwcBDwIBCBEBAwEBIQE?= =?us-ascii?q?GAwICAjAUAwMDCAIEAQ0FCBqDAYF5TQMuAQKhZQKBOIhhdYEygn4BAQWEfxi?= =?us-ascii?q?CDAmBNowZGoFBP4ERR4IeLj6ESzSCWjKCLI1JAYJ0hVckiT+PJQqCNpY1gka?= =?us-ascii?q?HfZAYg0eLDJpZAgQCBAUCDgEBBYFpIoFYcBU7gmxQGA2DDIoGOIM7ilN0gSi?= =?us-ascii?q?MMwEwXwEB?=
X-IronPort-AV: E=Sophos;i="5.69,402,1571702400"; d="scan'208,217";a="695487306"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Jan 2020 12:18:48 +0000
Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 006CImKM001455 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 6 Jan 2020 12:18:48 GMT
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 6 Jan 2020 06:18:47 -0600
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 6 Jan 2020 06:18:46 -0600
Received: from NAM10-BN7-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; Mon, 6 Jan 2020 07:18:46 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LRMvHJ8Eib82GYE66m80NQfXxZBPhhIm3fyDiByL5JBi+H5XBOHaf1uTif6U0YdmMfQ73ZXQ2WSf3ThExSTpYIp07iS6Fo0b5rMasdIWAiUyX3vFxj4nT4PisShhjCIU66r2ok8Flknm3uVGKwY1WGac6LXEqtU2Lo/wznx9eAUCSdRe2EpDHAOj1VIr93jv6JPGeb3tHcicA4/jSq8cLE5dQjwfmgvV9gB+k3CM8/m9IfTrohRdP4efO+xojJkZT+dVcgWgWVwD1wr2rHTrhR0+7vf3eMimUtCbgqvk1+/7lhmUEzKCDSpmacMQifX+VCA8w7WLRvM1oDFjx5FaUg==
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=92360DJvFc+QoZMw+E44UEke6MEQXvhA9YlqR7XAN+0=; b=AE3wpiR6390xPDC1OWDvzJVroOb/3vhFI1UfxPFswPZiowXIHIRhCU3dD6NPrsC6koBNrcmAJR4hjAWvpA0Bh/FXdLJ3fko326y8mKVQ0Qp2xyhfpZRnYLviAFI4PjUiilQzDc/wpLxcrNDtWeZNz+Jcn2pOSWJvOEJ79rRViAt5jBIV8ZqpObyp4KfwFV064UxEt5hZv9/aEvbCp2mcB+ISaxNDanLRQdQbasCXWFygYredT/KMYjpswQp7se36iSZT79qAEoxHxntreFnvJA0lhSp9E3AZHH8KhWdZ4MzHRysyyzKZaPkCcMysmKMAWQJxgazfLc0re1IDsRkFhQ==
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=92360DJvFc+QoZMw+E44UEke6MEQXvhA9YlqR7XAN+0=; b=c74sXUewDqxjXVi7GtAVErvZIYiEUauwQrgvCRUM7+COGTaGGSnVjvu/822G9YFAGHImtCb+ULvkw0bI6uC6UNVtXM9qS96Nk3N9EhKhWlOgcCqKPEg8yendU2Y2oVZsifOi0qP43QHkaW4+lbdJHkjSbsBpXYfSke1Yf7+wWNw=
Received: from MN2PR11MB4366.namprd11.prod.outlook.com (52.135.38.209) by MN2PR11MB3792.namprd11.prod.outlook.com (20.178.253.223) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.11; Mon, 6 Jan 2020 12:18:44 +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.2602.015; Mon, 6 Jan 2020 12:18:44 +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: AQHVwiHAhYPm4supIEC1a0DEsx4a2Kfc62iAgACLuiA=
Date: Mon, 6 Jan 2020 12:18:44 +0000
Message-ID: <MN2PR11MB4366BA114707B2A9BC2EDB6CB53C0@MN2PR11MB4366.namprd11.prod.outlook.com>
References: mailman.206.1577157479.6898.ccamp@ietf.org <202001031836012280585@zte.com.cn> <3B0A1BED22CAD649A1B3E97BE5DDD68BD382DAEF@dggeml532-mbs.china.huawei.com>
In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68BD382DAEF@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: 742676ac-4b52-418b-4a45-08d792a29320
x-ms-traffictypediagnostic: MN2PR11MB3792:
x-microsoft-antispam-prvs: <MN2PR11MB3792E54160DD5C0222D73331B53C0@MN2PR11MB3792.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0274272F87
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(366004)(396003)(346002)(39860400002)(376002)(199004)(51444003)(189003)(10533003)(4326008)(316002)(86362001)(110136005)(7696005)(66446008)(66476007)(71200400001)(64756008)(186003)(478600001)(26005)(6506007)(53546011)(33656002)(9686003)(8936002)(55016002)(81166006)(81156014)(76116006)(66946007)(66556008)(52536014)(2906002)(5660300002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3792; 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: AOsrPAbjJVqeVYHAPULkJQ1kKmW48wU6l0tjfdzAuiOoBXmABNssvFZvzWaez9Jy9RvW40idANn4djj2JThV65kqtgqWoVezY1ni/oBW3Nd5PfPK4vGGiYZtduTE5/ao1nNIl/C1ERpqHU6Kup6vRc8rMKAvUpRpD0iwNCCiMKpLWY7SusA+3WfK/z1wNOBAruShRCs9b7PQS1OyxjI0U76f0zD0RDfv0Gd4yDohcj7kGq8231FEdrl7V9cmCREAxT69NNGAT41o1gKJtsS05sVdJ7L79vXRelELZKWiJ6Z1CuKss1ZJmXIOrsIREMC+FMeXgULQq9sNKnrLx3tj1nnM97xJ0h/W16cHfYd+LU3umkRxgWizaoNmOJbLPV/Brz1o1tN95LNwYtulrWDUVqPDNWnoxucdXmn/Xz/n/uBCERur1lboYiSQzhpRfUoioay7h5CTXvT0fl+JJ6o3vBKYUMykfaVdaG+CFm57AF3qCdbJe/VDWfv3Zv2FV8MC+lbxop1D3Et4PnEiVGwSPQ==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR11MB4366BA114707B2A9BC2EDB6CB53C0MN2PR11MB4366namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 742676ac-4b52-418b-4a45-08d792a29320
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jan 2020 12:18:44.5829 (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: e66prw4cPRC3gN2djv4l8Sbj3Yb4nKLz1Jvm8Mc3UoREtJJPD1YGuURr6BAi0Sm/DtBKbkIe/zo5jUNr5JksjQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3792
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.16, xch-aln-006.cisco.com
X-Outbound-Node: alln-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/8E10_uFydud8rImwzvR0w2Mc8wM>
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: Mon, 06 Jan 2020 12:18:53 -0000

Please see [RW] inline for my comments:

From: CCAMP <ccamp-bounces@ietf.org> On Behalf Of Jiangyuanlong
Sent: 06 January 2020 02:20
To: 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]

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