Re: [CCAMP] Comments on draft-jiang-ccamp-flexe-ifmps & draft-jiang-ccamp-flexe-yang

Daniele Ceccarelli <daniele.ceccarelli@ericsson.com> Thu, 21 November 2019 11:45 UTC

Return-Path: <daniele.ceccarelli@ericsson.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 0AB97120AE8 for <ccamp@ietfa.amsl.com>; Thu, 21 Nov 2019 03:45:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
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 BY3dy3atiE5X for <ccamp@ietfa.amsl.com>; Thu, 21 Nov 2019 03:45:06 -0800 (PST)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40073.outbound.protection.outlook.com [40.107.4.73]) (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 0867B120801 for <ccamp@ietf.org>; Thu, 21 Nov 2019 03:45:05 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=b7msAyM1pjQ25mwsLObVXgjQooo7jchpyvUtDn/n389oxpk2za0sOYylUVqNNJj5VlVzOfibNYlti/mx4soK3aCW8XLDK+0SzP/EYySapjJ4S/BmG50lPHVx5g4Wb/a1nGrasAYD/H9VidDozJxy7bBS2UnPgEOmYgZVF6Q6R1ybDp2INGx7oQbaS2q8RPuKcS2IVXh34Wht0gzbEaki+x44pUz76ft9GU65ufWToXDGqKWIKCyhqCCepV2s3abv1sl7+A6lLI8aiuz0V6ysAk2Re0rDC+lzTCVtmn3nYjhajflEYclIRR0MYlddyUprtyfO7TOJ7tdK/6EZQlL3dQ==
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=fOvCVeLtgoE1+L4winKRWVqvmr0E+Sjv0WXJE06LkM0=; b=TkUz6Wsi6pxkKcG75eLbIKOER8OaJbJJSpU4L2FG4dawOuZXTz1oXWV5Fa2j8YH6HndDyMYOSVUwr58E39Alz5LOgpkS4kLJgFdO4hr5TqlIxSurib/9ONQgja1fWrmF3Wx2HIX4Xmy5D/mvpPLG8/x5xf31t4VEHS8ep1A5VNTTMCIlTZR4vAXQhsJwd0N92gYctuXQlauOma1FdDR/gELcwRhTDPTnxbcjcFHUV42ZV1CdwuHcPmBHqEiN2hUr5xolxfgIBWuvK5Sldswf2/HURsWlPSsc9uHGmcNAS2aUCY2JGGfF+WP+PX/Mmp9MqO8tJMlgKTO3fVFMGuoLZA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fOvCVeLtgoE1+L4winKRWVqvmr0E+Sjv0WXJE06LkM0=; b=AxmHoPUxyp+ylq9kjJpFabvKhP/ac+b5yZEHvnXMLaHS4ktmk/HXpHHw6ddbjlaX1LXkHpMQoymWEn1oFUNAXzjzH7I14M5IOyens2N2jnxjxpP16SzRnt78D99zE5k57uDl5LtR38VDhaWVdbc2fQjS/Kr4W9hbvSLRRwRiCaQ=
Received: from HE1PR0701MB2267.eurprd07.prod.outlook.com (10.168.35.143) by HE1PR0701MB2665.eurprd07.prod.outlook.com (10.168.187.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.10; Thu, 21 Nov 2019 11:45:03 +0000
Received: from HE1PR0701MB2267.eurprd07.prod.outlook.com ([fe80::1538:78dd:febc:6030]) by HE1PR0701MB2267.eurprd07.prod.outlook.com ([fe80::1538:78dd:febc:6030%4]) with mapi id 15.20.2474.019; Thu, 21 Nov 2019 11:45:02 +0000
From: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
To: Jiangyuanlong <jiangyuanlong@huawei.com>, "wang.qilei@zte.com.cn" <wang.qilei@zte.com.cn>, "ccamp@ietf.org" <ccamp@ietf.org>
Thread-Topic: [CCAMP] Comments on draft-jiang-ccamp-flexe-ifmps & draft-jiang-ccamp-flexe-yang
Thread-Index: AQHVoAzHtoOGRol5MEu+LNCP6tYC3qeVR6EAgAA4iiA=
Date: Thu, 21 Nov 2019 11:45:02 +0000
Message-ID: <HE1PR0701MB2267CF64D2744FBD9DDF1BBBF04E0@HE1PR0701MB2267.eurprd07.prod.outlook.com>
References: <201911210940406143805@zte.com.cn> <3B0A1BED22CAD649A1B3E97BE5DDD68BD378F50A@dggeml512-mbx.china.huawei.com>
In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68BD378F50A@dggeml512-mbx.china.huawei.com>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniele.ceccarelli@ericsson.com;
x-originating-ip: [93.38.67.165]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 81eef69d-5dc4-4bc9-9ec0-08d76e783f16
x-ms-traffictypediagnostic: HE1PR0701MB2665:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <HE1PR0701MB2665431D24CFE1196B04212FF04E0@HE1PR0701MB2665.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0228DDDDD7
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(346002)(136003)(376002)(396003)(39860400002)(199004)(189003)(478600001)(9686003)(53546011)(6116002)(7736002)(8676002)(8936002)(81156014)(81166006)(52536014)(3846002)(5660300002)(256004)(44832011)(606006)(966005)(66066001)(790700001)(71190400001)(71200400001)(14444005)(14454004)(446003)(6246003)(186003)(229853002)(55016002)(733005)(7696005)(6436002)(110136005)(26005)(54896002)(6306002)(236005)(33656002)(76116006)(74316002)(11346002)(2906002)(25786009)(2201001)(316002)(64756008)(66446008)(66616009)(66476007)(66556008)(2501003)(6506007)(102836004)(86362001)(66946007)(99286004)(76176011); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2665; H:HE1PR0701MB2267.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: etcWk/LkuZHawlgHtci98joNgcYs+nibFkxP536tRXZpe4C/kIyTYl7VsCdqQmwtBsRDB9Mn6sjkYlBguK5RMXjRIDtMRsLpmyl4R84yX1eIQ5TH28aeEdLe3peLPYSgRh0lWw14ztarSfdkXmDdO/5WmBJh/BrKgwieImey2vzyDGLfsiWlVVyAoivB1H6liXAsdL7FVVclxSIk6ckTlJG9DjnHpkh+XFtPDbnwP6LsVVTFBv4zP036fcGlRKZjgCrbwo1ptItcxfCvmcwbaFBTOriEbLrKUqeE/Fclr1faANK4DO+KIU5uv04nNRYvT7r4yS4tCEqW/Zoxj/Zw9iDSxl4pCZ+BxH8Np1/hvZ0FFNAuqrBijoimNxXABTyyYEP6Akl7Lhho8ZzYg9opG3YtuwJgLiQmwF+1fmT+IKQ40KdbyxZCqpqjrb+8OA2lNnGd0kt3pSNPDKPCfg3TzDJBBYWaxqbOTiZWNLvSLps=
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; micalg="SHA1"; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_02D4_01D5A069.7C809730"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 81eef69d-5dc4-4bc9-9ec0-08d76e783f16
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Nov 2019 11:45:02.8023 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: LoWqYjJGmz3VWbyaP6tLqELLxe0jU4hQQZqmPs5Ws8cnU5gg0EN5r6rGr78iKHUu3dpXaWYdCTlwwsjSky21A7dXzjXd+U8m1c4zpDxDMMI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2665
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/XM7c5Z1Y-fSxDwUltfnEyplqlGc>
Subject: Re: [CCAMP] Comments on draft-jiang-ccamp-flexe-ifmps & draft-jiang-ccamp-flexe-yang
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: Thu, 21 Nov 2019 11:45:14 -0000

Authors,

 

Instead of providing a table describing what’s wrong in the other draft, could you please spend some effort in putting together a table with the agreements and the disagreements?

I would like to start working on the agreements, see if there is enough meat to put together a very basic joint draft and then we can discuss disagreements one by one (and maybe find tradeoffs).

 

I would like to avoid calling for consensus for one or the other because, like in politics, I don’t think people agree will each and every statements made by one or the other party. 

Identifying a common part and building on top of it item by item is to me the best way forward.

 

Do you thinks this is possible? 

Thanks,

Daniele  

 

From: CCAMP <ccamp-bounces@ietf.org> On Behalf Of Jiangyuanlong
Sent: den 21 november 2019 09:16
To: wang.qilei@zte.com.cn; ccamp@ietf.org
Subject: Re: [CCAMP] Comments on draft-jiang-ccamp-flexe-ifmps & draft-jiang-ccamp-flexe-yang

 

Hi Qilei, 

 

Thank you much for all the comments, please see my replies inline.

 

Thanks,

Yuanlong

 

From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of wang.qilei@zte.com.cn <mailto:wang.qilei@zte.com.cn> 
Sent: Thursday, November 21, 2019 9:41 AM
To: ccamp@ietf.org <mailto:ccamp@ietf.org> 
Subject: [CCAMP] Comments on draft-jiang-ccamp-flexe-ifmps & draft-jiang-ccamp-flexe-yang

 

Dear Authors,

 

Personally speaking, I think there are some drawbacks in your model. 

[Jiang] Would appreciate much if you can provide a similar table as we provided in slide 15 & 16 of slides-106-ccamp-7-yang-data-model-for-flexe-interface-management-01.

The model should be comprehensive to support the configuring of any types FlexE capable functions/devices. For the control/management modelling work, we should not assume to much about the implementing of devices. The data model should be able to be applied in different cases. We should avoid the developing of the vendor specific model. The model we are developing should be capable of being applied to various kinds of device. 

[Jiang] Agreed, and that is our intent.

The draft-xiaobn-ccamp-flexe-yang-mod is progressing towards this direction.

 

Comments on some PS in your slides:

PS2:Slot-status should be enumerated

Comments: I agree with this, but I suspect whether the model in draft-jiang can deal with every cases. According to the description in FlexE IA, Usually, the unavailable slots are placed at the end of each relevant sub-calendar (the highest numbered slots). Could you please give some clarification that whether your model support the unavailable slot distributed over several sub-calendars, i.e., FlexE instance? In draft-xiaobn-ccamp-flexe-yang-mod, it can be well dealt with by indicating the unavaile slots number on different instances.

[Jiang] Definitely, unavailable slots can be marked in flexe-slot-status (a leaf of calendar-slot-list) in our model. Actually, this model provides a clear status indication of {used, unused, unavailable} for each slot. On the contrary, in your model, unused slots are not in bookkeeping, thus unused slots can only be determined after traversing all the flexe-clients (deduct the used slots for each client from the overall calendar slots) which is not efficient.

PS3: how to configure FlexE? only PHY, FlexE group, FlexE client, slot mapping are mentioned in your draft.

Comments: the figure on page 4 of your slides is not from the latest version of FLEXE IA. The latest version replace the FlexE PHY number with FlexE instance number. In OIF FLEXE IA and ITU-T G.8023 Amd1, the descritpion explicitly tell that the allocation and verification of slots are done at instance level. Why does your model just manipulate at PHY level and not align with FLEXE IA and G.8023 Amd1? 

draft-xiaobn-ccamp-flexe-yang-mod aligns with FLEXE IA and G.8023 Amd1 well.

[Jiang] slide 10 in slides-106-ccamp-7-yang-data-model-for-flexe-interface-management-01 answers this question. It seems your model cannot align with FlexE 1.0 & FlexE 1.1, as FlexE instance was first introduced in FlexE 2.0. Furthermore, exposing all management information defined in G.8023 Amd1 as you proposed is discouraged even in ITU-T SG15. 

PS4: implement overhead information or not?

• A negotiation protocol between calendars is introduced

• CCA, CCB, CC, CR, CA should be data plane internal artifacts, NOT necessary to be exposed

 

Comments: for the first item, the negotiation protocol is not clear.

I can not find any description about this in FlexE data plane documents. Currently, only static and master/slave are described in the data plane documents, which are relevant to the negotiation between source and destination devices. It would be better to align with data plane. It is not a good idea to invent new technology for this, as this will bring confusion.

[Jiang] As we already replied on the site, it is just an introduction of OIF defined overhead for calendar switching, see FlexE 2.0 and 2.1. There is nothing to be invented.

For the second item, I would say CC, CR and CA is data plane internal artifacts, but for CCA and CCB, it's not. Example below:

Please see the two figures below. For the first case, controller is responsible for deciding the initial A or B calendar configuration installed on the data plane devices; for the second case, the device is responsible for deciding A or B calendar configuration. It looks your model can only deal with the second case by assuming these calendar configuration functions implemented on the device. This is dangeous way for modelling work. The model should be comprehensive, and could deal with all kinds of devices. draft-xiaobn-ccamp-flexe-yang-mod could be applied in all the cases mentioned above.

[Jiang] IMO, both case 1 and case 2 as you describe are optional solutions. Under what circumstance that a controller needs to know details of CCA & CCB (maybe quite a large table as each slot needs an item respectively) and configure both of them will be a more valid use case (in our analysis, writing to CCA & CCB at the same time will cause loss of traffic on all the FlexE clients, thus should best be avoided). As an optional solution for your case 1, a controller/NMS can provide a single initial calendar configuration for the device, and the device then installs them on calendar A directly (in initiation as you says). If there is any device which happens to be switched to CCB, it must be capable to be initialized to CCA or switched back to CCA by an RPC command, that will be much simpler compared with managing both CCA & CCB on the controller/NMS as your model suggested (while also taking the risk in loss of traffic on all existing FlexE clients). 

 

 



 

PS6: support of bidirectional transport or not

• FlexE links are all bidirectional symmetric links so far

• Unidirectional parameters Tx/Rx should NOT be considered till the real use case

 

Comments: Please think about the case that the slots allocated for bidirectional transport are asymmetric.

We authors from https://tools.ietf.org/html/draft-xiaobn-ccamp-flexe-yang-mod-03 talked about this. I also confirmed this with FlexE IA editor Steve Trowbridge.

[Jiang] transport network is typically bidirectional asymmetric, even in future if asymmetric bandwidth is needed like in PON network, the module can be easily augmented to add RX attributes (IMHO, we don’t see such a need yet). 

The FlexE yang model draft from you is based on the problem statement draft, so the above issues exist in the yang model as well.

 

Thanks

Qilei