[OPSAWG] feedback on composed VPN
"Roni Even (A)" <roni.even@huawei.com> Mon, 17 June 2019 09:01 UTC
Return-Path: <roni.even@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 BF1A612009E for <opsawg@ietfa.amsl.com>; Mon, 17 Jun 2019 02:01:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.19
X-Spam-Level:
X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 8K2g8y6Mu9Ds for <opsawg@ietfa.amsl.com>; Mon, 17 Jun 2019 02:01:06 -0700 (PDT)
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 4B7B2120092 for <opsawg@ietf.org>; Mon, 17 Jun 2019 02:01:06 -0700 (PDT)
Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id C253972F0E8E09048D7F for <opsawg@ietf.org>; Mon, 17 Jun 2019 10:01:03 +0100 (IST)
Received: from lhreml708-chm.china.huawei.com (10.201.108.57) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 17 Jun 2019 10:00:37 +0100
Received: from lhreml708-chm.china.huawei.com (10.201.108.57) by lhreml708-chm.china.huawei.com (10.201.108.57) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Mon, 17 Jun 2019 10:00:37 +0100
Received: from DGGEMM403-HUB.china.huawei.com (10.3.20.211) by lhreml708-chm.china.huawei.com (10.201.108.57) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Mon, 17 Jun 2019 10:00:37 +0100
Received: from DGGEMM526-MBX.china.huawei.com ([169.254.8.116]) by DGGEMM403-HUB.china.huawei.com ([10.3.20.211]) with mapi id 14.03.0439.000; Mon, 17 Jun 2019 17:00:02 +0800
From: "Roni Even (A)" <roni.even@huawei.com>
To: "opsawg@ietf.org" <opsawg@ietf.org>
CC: "xuhl.bri@chinatelecom.cn" <xuhl.bri@chinatelecom.cn>, Qin Wu <bill.wu@huawei.com>, "Wubo (lana)" <lana.wubo@huawei.com>
Thread-Topic: feedback on composed VPN
Thread-Index: AdUk6lYZmNWqdoP4Rz+PHtVdYN/QPA==
Date: Mon, 17 Jun 2019 09:00:01 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD18D37409@dggemm526-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.200.202.60]
Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD18D37409dggemm526mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/a2fc3WwsMdUr9tly_D0MNEiIW3U>
Subject: [OPSAWG] feedback on composed VPN
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, 17 Jun 2019 09:01:09 -0000
Hi, For some reason this email is not in the mailing list archive and I did not see it. Thanks for the review See my response inline Thanks Roni Even 发件人: Xu honglei [mailto:xuhl.bri@chinatelecom.cn] 发送时间: 2019年6月17日 12:11 收件人: opsawg@ietf.org<mailto:opsawg@ietf.org> 主题: feedback on composed VPN I have read the latest version of draft-evenwu-opsawg-yang-composed-vpn-03. I believe it aims at decomposing VPN service spanning across domain into VPN service in each domain and provide end to end connectivity service delivery, in addition, I believe it can also stitch connectivity service in each domain and provide end to end network visibility to the connectivity service. Here are a few comments: 1.When a VPN service needs to span different administrative domains, usually VPN service in two end or two site in the access are same type VPN service, I would suggest to change spaning two AS into three domains or AS, introduce L2VPN in two end close to the site RE: thanks, this is a good scenario, maybe we can add this to figure 2 and explain the logic behind it. 2. It is not clear to what config manger1 means? It is domain specific controller or NMS or something else, I think it is former, if the answer is yes, it will be great to make this clear. RE: this is a domain specific controller see the text after figure 1 but we can make it clearer Besides this, I think this draft is in good shape and ready for adoption. H.Xu +86-010-5090-2313 +86-133-0116-8970 xuhl.bri@chinatelecom.cn<mailto:xuhl.bri@chinatelecom.cn> ---------------------------------------------------------------------------------------------------------------------- China Telecom Corporation Limited Beijing Research Institute Southern Zone of Future Science City, Beiqijia Town, Changping District, Beijing, China 102209
- [OPSAWG] feedback on composed VPN Roni Even (A)