IETF Logo Mail Archive

Re: [bess] Some questions on E-Tree (RFC8317) services with VXLAN Encapsulation: is it feasible? is it necessary? is it under definition already?

"Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com> Wed, 07 February 2018 07:40 UTC

Return-Path: <jorge.rabadan@nokia.com>
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 D4FEE1201FA for <bess@ietfa.amsl.com>; Tue, 6 Feb 2018 23:40:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 1NZxGGVOcOr5 for <bess@ietfa.amsl.com>; Tue, 6 Feb 2018 23:40:30 -0800 (PST)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0096.outbound.protection.outlook.com [104.47.0.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69EAC1200C1 for <bess@ietf.org>; Tue, 6 Feb 2018 23:40:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vyT0Y6ok2D5AgFAaKcI7uhKXsIiWI1xlq91gpPOg+94=; b=sDnrieFbxpZ1TuJrqnDpo+OCi1zDpet+i8VlYxZmGnBlUbhVNwKw9JPJuV3v+p6ceiigpOLRMpeMxm94bRyWnBLZToMj5JN6b7FvvyVXaNa1/J/e/7kcVuvf/SlApszFfcYn6LnQSK3QhvIgeK4BN5WZ75Lczu8eR5upWaBhpFg=
Received: from AM4PR07MB3409.eurprd07.prod.outlook.com (10.171.189.158) by AM4PR07MB3267.eurprd07.prod.outlook.com (10.171.189.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.485.3; Wed, 7 Feb 2018 07:40:25 +0000
Received: from AM4PR07MB3409.eurprd07.prod.outlook.com ([fe80::d9ae:4b20:1be2:42d4]) by AM4PR07MB3409.eurprd07.prod.outlook.com ([fe80::d9ae:4b20:1be2:42d4%3]) with mapi id 15.20.0485.009; Wed, 7 Feb 2018 07:40:25 +0000
From: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com>
To: "wang.yubao2@zte.com.cn" <wang.yubao2@zte.com.cn>, "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>
CC: "bess@ietf.org" <bess@ietf.org>
Thread-Topic: Some questions on E-Tree (RFC8317) services with VXLAN Encapsulation: is it feasible? is it necessary? is it under definition already?
Thread-Index: AQHTn+RzdDV9dpa6+Ee2jvjKEY0r0KOYns4A
Date: Wed, 07 Feb 2018 07:40:25 +0000
Message-ID: <0FEC8081-68F5-4BDE-A2A8-FCF55AAF1CC2@nokia.com>
References: <201802071522316402979@zte.com.cn>
In-Reply-To: <201802071522316402979@zte.com.cn>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.a.0.180204
authentication-results: spf=none (sender IP is ) smtp.mailfrom=jorge.rabadan@nokia.com;
x-originating-ip: [95.122.142.163]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM4PR07MB3267; 7:N00Y2RBR259l1HXqGDzfSOeTzcqr6GCNxpj6zou58VhQSD//KgPp/MDcWNRkMVGhWY2R4n/d1kps+/0pLISK7WP4M4p324H++PEMHol+wxZV1yx5DGW+R2xkxTkIby6VtGfrHKmc8I1/fbvWqi2DC3ZDfoH0FUterfMSz92qsrYqMAgRrJ3ZcMqGu06eZtsHO8TFlpxrZ3W7IrPa46jciRSF6bpaOLf1sh+HiBmvcNl0BUaZUO9G7N69BKo2iopk
x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR;
x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(376002)(346002)(39860400002)(366004)(39380400002)(396003)(199004)(189003)(3280700002)(3660700001)(83716003)(33656002)(9326002)(3846002)(478600001)(2201001)(6116002)(6436002)(14454004)(58126008)(110136005)(66066001)(316002)(53546011)(6506007)(1941001)(4326008)(105586002)(86362001)(7736002)(25786009)(82746002)(76176011)(97736004)(186003)(2950100002)(102836004)(26005)(6306002)(6246003)(54896002)(106356001)(6512007)(83506002)(53936002)(99286004)(8666007)(68736007)(6486002)(5250100002)(229853002)(8936002)(5660300001)(2501003)(81156014)(36756003)(2906002)(81166006)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR07MB3267; H:AM4PR07MB3409.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: aba7f792-75e6-40a2-41bb-08d56dfe0d49
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:AM4PR07MB3267;
x-ms-traffictypediagnostic: AM4PR07MB3267:
x-microsoft-antispam-prvs: <AM4PR07MB3267866D8792ECB578558BFAF7FC0@AM4PR07MB3267.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(61668805478150)(138986009662008)(82608151540597)(97927398514766)(95692535739014)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3231101)(11241501184)(806099)(2400082)(944501161)(3002001)(6055026)(6041288)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:AM4PR07MB3267; BCL:0; PCL:0; RULEID:; SRVR:AM4PR07MB3267;
x-forefront-prvs: 0576145E86
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: fjU9yvBe+ICJfSwKkUJ55Tz+vzXqRxNIsqSZCWw2ECgPFbZONyKR11S7GM7vrq/T5Hi3zhGfcYLOhSj1LbO4isrvUZbnGtfyvP+rYGYsdFPuT8py+IF/7dc4tbr1joDw
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_0FEC808168F54BDEA2A8FCF55AAF1CC2nokiacom_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: aba7f792-75e6-40a2-41bb-08d56dfe0d49
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Feb 2018 07:40:25.3881 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB3267
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/eO6yk9HIhhbaEybJs2YCXbl7UtQ>
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>
X-List-Received-Date: Wed, 07 Feb 2018 07:40:33 -0000

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

v2.23.0 | Report a Bug | By Email