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

Joe Clarke <jclarke@cisco.com> Thu, 08 November 2018 01:37 UTC

Return-Path: <jclarke@cisco.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2226130DE5; Wed, 7 Nov 2018 17:37:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.97
X-Spam-Level:
X-Spam-Status: No, score=-14.97 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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
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 Nel5HfhU1zrj; Wed, 7 Nov 2018 17:37:48 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F1C9130DE2; Wed, 7 Nov 2018 17:37:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5491; q=dns/txt; s=iport; t=1541641067; x=1542850667; h=to:references:from:subject:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=dJeJ6KvQXt4QwXhwUU48EVKWaOuVbFf8xzSFSjZMPCQ=; b=ZladfFPow+a43yBGPLvxCsATyBKegI1irqR/EcdfyMsrbnKYSw/s4I4t BYY43d5X69ZaYD1BNT1irO4ebq+R5KkT51hMrStDDpF05F9a8xlzmhLWg anzUvs8+2K0Pip1MZMaHjb9n5NfeexYWpDgB8CAEkQMAV5+gHSxVMyRF7 Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AJAADKkuNb/5xdJa1jGQEBAQEBAQEBAQEBAQcBAQEBAQGBUQQBAQEBAQsBgVUuZgNMMyeDeIgYi3yBYC2XMBSBZg0YDYQBRgKDCSI0DQ0BAwEBAgEBAm0cDIU6AQEBAQIBAQEhDwE7CRIJAhIGAgIjAwICJx8DDgYBDAYCAQGDHQGBeQgPjEKbUIEuhDECDAMPLoUxgQuKbReBQT+BESeCa4MbAQECAQEWgQ+DPIJXAokLhXN2j04Jhm+KHQYYgVdMhDWCfCaGbolSg0mKToFDOIFVTSMVGiGCbAmCIxISiEyFXCEDMAyNRgEB
X-IronPort-AV: E=Sophos;i="5.54,478,1534809600"; d="scan'208";a="467993924"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Nov 2018 01:37:46 +0000
Received: from [192.168.10.113] (rtp-jclarke-nitro4.cisco.com [10.118.87.85]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTP id wA81bhm6013283; Thu, 8 Nov 2018 01:37:44 GMT
To: "Wubo (lana)" <lana.wubo@huawei.com>, "opsawg@ietf.org" <opsawg@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
References: <520ECC8D9CA1724BA1CE492DF898F6A339699D@DGGEMI526-MBX.china.huawei.com>
From: Joe Clarke <jclarke@cisco.com>
Openpgp: preference=signencrypt
Autocrypt: addr=jclarke@cisco.com; prefer-encrypt=mutual; keydata= xsDiBDo1cJ0RBADSZSmbmzdRr1CoRWWKmAyu0eaQimaLV1TsZEML/ksLyg6faXrKIA/MWc7M w4FmKkDjaZdFzobzabnKp2QwVadLqi1gYY2WsApKC0rSoqsPx5E847AmwNWXgjXiXORXmnZL mf5PZ2ECOEJC27sji5Nrh9GSw7OPp6c+EE20gMNVrwCgu3iK5vyGQfy0/wX/jcIvP0nHznUD /RvijiKomyaf6F5pibmouFNeuCDHc8lwx2giA/MCZl/nSkI2/UX27sULGNgvKNkVPu/AukXu zW3fIthsJgjQZUoi/BTe9kUP+RL3+RALXXuLv7b3xGRHJ8A1Rpy9H43fkjHZ945YNPrUvJlG LP5PNGBD1xC21X3EGAyywVynDskcA/4qgbJFkVzmPjFJUjq+RW1zw3UIb3bbkskl/wk5qd+M w2EhiSPTbEhJQAQUvqSGFWEGp2ANic7iYLdPXV/O6I1/guRRaY0eK77YkkCjz1snaKYnGSeI GHGwmHb6D+ZHzTqZqr6IssgEIUHjXfgOUTARQbL15nJTVRzDGUiT/65R3c0eSm9lIENsYXJr ZSA8amNsYXJrZUBjaXNjby5jb20+wl8EExECABcFAjyDqGQFCwcKAwQDFQMCAxYCAQIXgAAS CRDN7TXCWm4C3wdlR1BHAAEB5KkAn0kBda/9+uF6RfnDSFS7RExUU9DqAJ4knRckYiSASteC K03QVtEiXblL287ATQQ6NXCeEAQAhIURlK17jmIMdMIuScFU6xK+jkKgVVFrjlRH5vLV2spp jH/uQ57MMGuOcs7PckXCnPjBV8Tm32Tuw+fCyrbc2gt0ouiT/5WWj0EMeAfWew1zBXX2okGf LqS6gucVDS6tcEFN6PmJEmX+tWDcmiqx/xXiSfMVYiLMdlK+YDkMDDsAAwUD/3BWOyfdnBGH Kv28zx+5wq/2vhYnUYCAdVD2ZWCJizQTMbkcxEIKAwtAj6yqKq9ah82nt4VHl5ZejVe47jvR 2nXwJ5VQ9eITuTjTLDw+3qr9lN077VZ32hyb5ULJcW756j9Z3YB2FTANw6KHgChaSVVx9kYJ FlAggraU7mi39/wvwk4EGBECAAYFAjo1cJ4AEgkQze01wlpuAt8HZUdQRwABAQbdAJ9R8SzU Mluu9r93BMv6fAW9j6qTZgCfYcEAqOMJv+3Z+YxLiDtWcCY4Sfo=
Organization: Cisco
Subject: Re: [OPSAWG] Fwd: New Version Notification for draft-sun-opsawg-sdwan-service-model-01.txt
Message-ID: <46c5ba10-8aca-4cb5-e69a-f6c44687ed73@cisco.com>
Date: Wed, 07 Nov 2018 20:37:42 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.3.0
MIME-Version: 1.0
In-Reply-To: <520ECC8D9CA1724BA1CE492DF898F6A339699D@DGGEMI526-MBX.china.huawei.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Outbound-SMTP-Client: 10.118.87.85, rtp-jclarke-nitro4.cisco.com
X-Outbound-Node: rcdn-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/0_ZOzkj2Zm1UbgN5BnNVzcVD0JY>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Nov 2018 01:37:51 -0000

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?

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.

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
>