Re: [bess] Some questions on E-Tree (RFC8317) services with VXLAN Encapsulation: is it feasible? is it necessary? is it under definition already?
<wang.yubao2@zte.com.cn> Wed, 28 February 2018 00:43 UTC
Return-Path: <wang.yubao2@zte.com.cn>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62FA12EACB for <bess@ietfa.amsl.com>; Tue, 27 Feb 2018 16:43:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.208
X-Spam-Level:
X-Spam-Status: No, score=-4.208 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_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 AK_OkUFpy3FH for <bess@ietfa.amsl.com>; Tue, 27 Feb 2018 16:42:58 -0800 (PST)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (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 85CB1127775 for <bess@ietf.org>; Tue, 27 Feb 2018 16:42:58 -0800 (PST)
Received: from mxct.zte.com.cn (unknown [192.168.164.217]) by Forcepoint Email with ESMTPS id 5043F28FB37776C382E8 for <bess@ietf.org>; Wed, 28 Feb 2018 08:42:56 +0800 (CST)
Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Forcepoint Email with ESMTPS id 3F5C0DC4C0C93B21EB78 for <bess@ietf.org>; Wed, 28 Feb 2018 08:42:56 +0800 (CST)
Received: from [127.0.0.1] ([10.30.12.226]) by mse01.zte.com.cn with ESMTP id w1S0gsvl036151 for <bess@ietf.org>; Wed, 28 Feb 2018 08:42:54 +0800 (GMT-8) (envelope-from wang.yubao2@zte.com.cn)
Received: from njxapp03.zte.com.cn ([10.41.132.202]) by mse01.zte.com.cn with SMTP id w17AHqil057809; Wed, 7 Feb 2018 18:17:53 +0800 (GMT-8) (envelope-from wang.yubao2@zte.com.cn)
Received: from mapi (njxapp04[null]) by mapi (Zmail) with MAPI id mid203; Wed, 7 Feb 2018 18:17:54 +0800 (CST)
X-Zmail-TransId: 2afc5a7ad252ffffffffadb-560e9
X-Mailer: Zmail v1.0
Message-ID: <2018020718175481991562111@zte.com.cn>
Mime-Version: 1.0
From: wang.yubao2@zte.com.cn
To: jorge.rabadan@nokia.com
Cc: bess@ietf.org, sajassi@cisco.com, ssalam@cisco.com, jdrake@juniper.net, ju1738@att.com, sboutros@vmware.com
Content-Type: multipart/alternative; boundary="=====_003_next====="
X-MAIL: mse01.zte.com.cn w1S0gsvl036151
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/avYlNW_qADQpdsQMXzh2W6YVhYM>
Subject: Re: [bess] Some questions on E-Tree (RFC8317) services with VXLAN Encapsulation: is it feasible? is it necessary? is it under definition already?
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
Date: Wed, 28 Feb 2018 00:43:02 -0000
X-Original-Date: Wed, 7 Feb 2018 18:17:54 +0800 (CST)
X-List-Received-Date: Wed, 28 Feb 2018 00:43:02 -0000
Thanks for your explanations. So the extensions is based on GENEVE and RFC8317, Glad to see your working on EVPN extensions for GENEVE in the future. I have mixed GENEVE with VXLAN, and I didn't see a leaf-label extension in GENEVE, so I asked the question. I get the point now, Best wishes. //Hi, // //Since the overlay tunnel encapsulation selected by NVO3 is GENEVE, IMHO we should only work on EVPN extensions for GENEVE. VXLAN does not have the required //extensibility. //And indeed, we are working on EVPN extensions for GENEVE that will address RFC8317 E-Tree services. // //SRv6 is a different beast. // //Finally, Local Bias can be used for all-active multi-homing, but not for E-Tree, or at least I fail to see how you would do it. // //My 2 cents. //Jorge From: "wang.yubao2@zte.com.cn" <wang.yubao2@zte.com.cn> Date: Wednesday, February 7, 2018 at 8:22 AM To: "sajassi@cisco.com" <sajassi@cisco.com>, "ssalam@cisco.com" <ssalam@cisco.com>, "jdrake@juniper.net" <jdrake@juniper.net>, "ju1738@att.com" <ju1738@att.com>, "sboutros@vmware.com" <sboutros@vmware.com>, "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com> Cc: "bess@ietf.org" <bess@ietf.org> Subject: Some questions on E-Tree (RFC8317) services with VXLAN Encapsulation: is it feasible? is it necessary? is it under definition already? Hi folks, I have some questions on E-Tree services with VXLAN Encapsulation, 1) It seems that RFC8317 only defines E-Tree service in MPLS (or PBB over MPLS EVPN) encapsulation. but there are other EVPN encapsulations, VXLAN and SRv6, and the SRv6 EVPN solution also defined the E-Tree procedures framework with Arg.FE2 included in DT2M SIDs so, is the E-Tree service with VXLAN Encapsulation feasible? is it necessary? is it under definition already? 2) i think the primary design with E-tree over MPLS EVPN is ESI/Leaf Label, but in VXLAN encapsulation, there is no ESI Label or Leaf Label, so, although it can do ESI filtering procedures with "Local Bias" procedure and without ESI Label information, the VXLAN Encapsulation can't do E-tree filtering procedures without Leaf Label? is it right or i have missed something? Best Regards, Wang Yubao
- Re: [bess] Some questions on E-Tree (RFC8317) se… wang.yubao2
- Re: [bess] Some questions on E-Tree (RFC8317) se… wang.yubao2
- Re: [bess] Some questions on E-Tree (RFC8317) se… wang.yubao2
- Re: [bess] Some questions on E-Tree (RFC8317) se… wang.yubao2
- Re: [bess] Some questions on E-Tree (RFC8317) se… wang.yubao2
- Re: [bess] Some questions on E-Tree (RFC8317) se… wang.yubao2
- Re: [bess] Some questions on E-Tree (RFC8317) se… wang.yubao2