[OPSAWG] pros & cons of draft-sun-opsawg-sdwan-service-model aligning with MEF SD-WAN or ONUG SD-WAN

Linda Dunbar <linda.dunbar@huawei.com> Mon, 07 January 2019 02:23 UTC

Return-Path: <linda.dunbar@huawei.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A92B11292F1; Sun, 6 Jan 2019 18:23:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 Aa1Q5ugUUIyv; Sun, 6 Jan 2019 18:23:11 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 67E8612872C; Sun, 6 Jan 2019 18:23:11 -0800 (PST)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id E5C366CFA1152A7872E5; Mon, 7 Jan 2019 02:23:08 +0000 (GMT)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 7 Jan 2019 02:23:08 +0000
Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.185]) by SJCEML701-CHM.china.huawei.com ([169.254.3.117]) with mapi id 14.03.0415.000; Sun, 6 Jan 2019 18:23:03 -0800
From: Linda Dunbar <linda.dunbar@huawei.com>
To: "opsawg@ietf.org" <opsawg@ietf.org>, "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
CC: "draft-sun-opsawg-sdwan-service-model@ietf.org" <draft-sun-opsawg-sdwan-service-model@ietf.org>
Thread-Topic: pros & cons of draft-sun-opsawg-sdwan-service-model aligning with MEF SD-WAN or ONUG SD-WAN
Thread-Index: AdSmLTcugN3+1ZDVSOqR8fQYWNi4aQ==
Date: Mon, 07 Jan 2019 02:23:03 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F66B22246C@sjceml521-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.137.73]
Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F66B22246Csjceml521mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/ZwTIGkuYHkdGapVtH2DYnGGk6U4>
Subject: [OPSAWG] pros & cons of draft-sun-opsawg-sdwan-service-model aligning with MEF SD-WAN or ONUG SD-WAN
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Jan 2019 02:23:14 -0000

I watched the video recording of IETF 103 OPSAwg session over the Christmas break and want to add some comments (as I missed attending the session in Bangkok due to conflicts).

Both MEF and ONUG have SD-WAN related initiatives. As Charles Eckel stated in the opsawg IETF 103 session that MEF is more from service provider's perspective, whereas ONUG is more from single vendor's perspective.

ONUG has Path Service model and Reachability service models, the purpose of the Path Service model is to normalize the service specification, so that it could be implemented through any vendor's controller (via API support).  Same for Reachability Service.  The goal is to be able to configure services within a vendor domain through a single API, with defined service behaviors.

So the requirements from MEF and ONUG are for different entity, I am not sure if we can create one service models for both MEF and ONUG.

Reading through the draft-sun-opsawg-sdwan-service-model, I feel it is more from service providers' perspective, i.e. more aligned with MEF.

I agree with AD Ignas' saying that we need to define service model per ONUG user community provided requirement.
The problem is that the requirements from ONUG User community are very high level (e.g. "aggregate paths from N service providers to access hybrid clouds"), which can't be directly translated to service model requirements. Engineers, like IETF community, have to bear the burden to derive the detailed executable service model from the high level requirement from User Community. I think a more realistic method is to bring the IETF service modes to MEF and ONUG to be validated.

Best Regards,
Linda Dunbar