Re: [OPSAWG] Fwd: New Version Notification for draft-sun-opsawg-sdwan-service-model-01.txt

"Wubo (lana)" <lana.wubo@huawei.com> Tue, 13 November 2018 10:02 UTC

Return-Path: <lana.wubo@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 7CEE7130DC4; Tue, 13 Nov 2018 02:02:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 GVydVSsnCK1D; Tue, 13 Nov 2018 02:02:51 -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 A8758130DC0; Tue, 13 Nov 2018 02:02:50 -0800 (PST)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 3698B50FF3826; Tue, 13 Nov 2018 10:02:46 +0000 (GMT)
Received: from DGGEMI403-HUB.china.huawei.com (10.3.17.136) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 13 Nov 2018 10:02:47 +0000
Received: from DGGEMI526-MBX.china.huawei.com ([169.254.8.168]) by dggemi403-hub.china.huawei.com ([10.3.17.136]) with mapi id 14.03.0415.000; Tue, 13 Nov 2018 18:02:43 +0800
From: "Wubo (lana)" <lana.wubo@huawei.com>
To: Joe Clarke <jclarke@cisco.com>, "opsawg@ietf.org" <opsawg@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
Thread-Topic: [OPSAWG] Fwd: New Version Notification for draft-sun-opsawg-sdwan-service-model-01.txt
Thread-Index: AdR7NrTfVBKD8O7tS9ibjYm3xj0VMg==
Date: Tue, 13 Nov 2018 10:02:42 +0000
Message-ID: <520ECC8D9CA1724BA1CE492DF898F6A33B18A8@DGGEMI526-MBX.china.huawei.com>
Accept-Language: en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.134.189.23]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/j7-k9zzv1P6QSu_QTYxfFLo6_L0>
Subject: Re: [OPSAWG] Fwd: New Version Notification for draft-sun-opsawg-sdwan-service-model-01.txt
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: Tue, 13 Nov 2018 10:02:54 -0000

Hi, Joe
 
Thanks for the review.
 
Please see in line.
 
Bo

-----邮件原件-----
发件人: Joe Clarke [mailto:jclarke@cisco.com] 
发送时间: 2018年11月8日 9:38
收件人: Wubo (lana) <lana.wubo@huawei.com>; opsawg@ietf.org; rtgwg@ietf.org
主题: Re: [OPSAWG] Fwd: New Version Notification for draft-sun-opsawg-sdwan-service-model-01.txt

On 10/22/18 05:09, Wubo (lana) wrote:
> Dear all,
> 
> We would like to define a CE-based VPN service model to differentiate 
> from PE-based L3&L2 service model. The link is at 
> https://tools.ietf.org/html/draft-sun-opsawg-sdwan-service-model-01
> 
> Since we feel the SD-WAN related work in IETF, like 
> https://tools.ietf.org/html/draft-dukes-spring-sr-for-sdwan-00, 
> https://tools.ietf.org/html/draft-rosen-bess-secure-l3vpn-01,
> https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-02, are all enhanced CE-based VPN. But there is no consistent SD-WAN or CE-based VPN service definition.
> In the drafts, each assumes a different SD-WAN functionality of CE, 
> like hybrid WAN and L3-L7 flow classification in SR for sdwan draft, and L3 virtual network separation inside IPSEC VPN In secure L3VPN draft.
> 
> So, in this draft, based on our understanding of SD-WAN service and 
> together with other SD-WAN draft, we define the SD-WAN main service components and hope that this will help clarifying the main service feature of SD-WAN and  helping to automate the service management.
> 
> We'd like to solicit more comments on whether this service model meets your thought of the SD-WAN service.

Bo, I read through your draft as well as solicited some feedback from colleagues.  I have a few questions as to scope and overall intent of your service model.

First, you mention that the service model is intended for a management system.  I'm confused as to what that means in the SD-WAN space.  It is my understanding that a controller or orchestrator is a main focus in an SD-WAN architecture.  So I was trying to rationalize your model as something one might instantiate on a controller.  Then the controller would handle configuring (or programming) the CEs.  Can you provide more clarity here?

[Bo] The model is to define a customer service model which is used for the northbound interface of SD-WAN service orchestrator, and a SD-WAN controller is instructed by the orchestrator to initiate the specific setting or controlling.
I will add more text to explain this.
Thanks.

The draft assumes that "MOST" of the capabilities will be enabled by configuration on the CE devices using this SM. This may not be true.

In Cisco's implementation of SD-WAN, one of the objectives is simplicity where we want to push minimal amount of config to the CE. These things include interface IPs, organization name, dynamic routing config, etc.
But most of the functions tied to SD-WAN are applied as policies on the controllers and are sent to devices as a policy update rather than configuration on the CE devices.

Some gaps in this model that would be needed for other SD-WAN implementations are:

* Security: The keys are automatically generated and propagated through the centralized controller using different protocols. Hence not much configuration is required on the CE.  I don't see how that would fit exactly into your model

* Policy templates: Some of the basic things are done utilizing the configuration on the device. Most of the classification/application group/profile(SLA)/ Path selection/etc are again done at the controller level and being sent to devices as policy/control update and not as configuration.

It comes back to where the model is instantiated.

Overall, I think this may be difficult to be broadly adopted as being able to describe all SD-WAN implementations as it is now.

[Bo] This model is not intended for CE configuration. 
I understand your concerns, as I also saw some SD-WAN drafts, https://tools.ietf.org/id/draft-rosen-bess-secure-l3vpn-01.txt
 and https://tools.ietf.org/id/draft-sajassi-bess-secure-evpn-00.txt are working to simplify the configuration of CEs, such as security parameters.
The security and policy related model definition are all input template for controller. 
Again, the idea is to define an abstract service model to describe common SD-WAN service functionality, such as virtual network separation and multiple WAN access choices within a customer network.
Thanks, Bo

Joe

> 
> Thanks,
> 
>  Bo, on behalf of the co-authors
> 
>> -----邮件原件-----
>> 发件人: internet-drafts@ietf.org [mailto:internet- drafts@ietf.org]
>> 发送时间: 2018年10月22日 15:53
>> 收件人: Qin Wu <bill.wu@huawei.com>; Honglei Xu 
>> <sunqiong.bri@chinatelecom.cn>; Wubo (lana) <lana.wubo@huawei.com>; 
>> Qiong Sun <sunqiong.bri@chinatelecom.cn>; Wubo (lana) 
>> <lana.wubo@huawei.com>
>> 主题: New Version Notification for draft-sun-opsawg- 
>> sdwan-service-model-01.txt
>>
>>
>> A new version of I-D, draft-sun-opsawg-sdwan-service- model-01.txt 
>> has been successfully submitted by Bo Wu and posted to the IETF 
>> repository.
>>
>> Name:		draft-sun-opsawg-sdwan-service-model
>> Revision:	01
>> Title:		A YANG Data Model for SD-WAN VPN
>> Service Delivery
>> Document date:	2018-10-21
>> Group:		Individual Submission
>> Pages:		40
>> URL:            https://www.ietf.org/internet-drafts/draft-sun-
>> opsawg-sdwan-service-model-01.txt
>> Status:         https://datatracker.ietf.org/doc/draft-sun-
>> opsawg-sdwan-service-model/
>> Htmlized:       https://tools.ietf.org/html/draft-sun-opsawg-
>> sdwan-service-model-01
>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-
>> sun-opsawg-sdwan-service-model
>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-sun-
>> opsawg-sdwan-service-model-01
>>
>> Abstract:
>>    This document defines a SD-WAN VPN service model to enable a 
>> Service
>>    Provider to deliver SD-WAN VPN services to its customers by
>>    provisioning the CE devices on behalf of the customer.
>> This document
>>    is based on provider-provisioned CE-based VPNs as described in
>>    [RFC4110].
>>
>>    This model provides an abstracted view of the SD-WAN VPN service
>>    configuration components, and is intended to be instantiated at 
>> the
>>    management system to deliver the overall service.
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of 
>> submission until the htmlized version and diff are available at 
>> tools.ietf.org.
>>
>> The IETF Secretariat
> 
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>