Re: [bess] Last call comment to draft-ietf-bess-evpn-inter-subnet-forwarding-05

"Ali Sajassi (sajassi)" <sajassi@cisco.com> Thu, 31 January 2019 06:10 UTC

Return-Path: <sajassi@cisco.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 6EDF8130EBA for <bess@ietfa.amsl.com>; Wed, 30 Jan 2019 22:10:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -19.053
X-Spam-Level:
X-Spam-Status: No, score=-19.053 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 RpyK469kOOhh for <bess@ietfa.amsl.com>; Wed, 30 Jan 2019 22:10:52 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBC22130D7A for <bess@ietf.org>; Wed, 30 Jan 2019 22:10:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20844; q=dns/txt; s=iport; t=1548915051; x=1550124651; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=JFeaa0qqpyREbmkFA6caSscZOp9U5Nk+WKvtyhnm9v8=; b=XcWx5dMG2G0MswGr/cKEXtCi8fuTZ9T09e1cacQ3gtgD9sm+A0Y1at8L /qKV3S5BJKN1JlmxLCY3ZST7eIRUUVRSEfW/TwzgaxLy8nJRMDxkWWA0J kjaydR5Xiip8EjCFP7CmgJyUZGXA6suF+i0RES49zzWPvolriVB9xPhQM g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AQAAAZkFJc/5tdJa1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVAEBAQEBAQsBgQ12Z4EDJwqDeZQNgWglkh+GA4FnCwE?= =?us-ascii?q?BhGwCF4JwIjcGDQEDAQECAQECbSiFSgEBAQQjZgIBCBEDAQEBKAMCAgIwFAk?= =?us-ascii?q?IAgQBEoMiAYEdZKx6gS+FQ4RzjEAXgX+BEScME4JMhEVcFoJTMYImApAHhn6?= =?us-ascii?q?LWQkCkjEYgWuFOosSihuRJwIRFIEnNSKBVnAVZQGCQZBcQTGOSIEfAQE?=
X-IronPort-AV: E=Sophos;i="5.56,543,1539648000"; d="scan'208,217";a="514422093"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Jan 2019 06:10:50 +0000
Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x0V6An3A015669 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 31 Jan 2019 06:10:50 GMT
Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 31 Jan 2019 01:10:49 -0500
Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1395.000; Thu, 31 Jan 2019 01:10:49 -0500
From: "Ali Sajassi (sajassi)" <sajassi@cisco.com>
To: Linda Dunbar <linda.dunbar@huawei.com>, "bess@ietf.org" <bess@ietf.org>
Thread-Topic: [bess] Last call comment to draft-ietf-bess-evpn-inter-subnet-forwarding-05
Thread-Index: AQHUuQwVi9GuU3fs0U21VBdde+DzFaXIuyrg///33gA=
Date: Thu, 31 Jan 2019 06:10:49 +0000
Message-ID: <8F2F4831-90A1-4561-B6E9-6B9C776CC9BB@cisco.com>
References: <F1F389CC-99F8-4504-8F44-2E21A0F8BDD0@cisco.com> <4A95BA014132FF49AE685FAB4B9F17F66B2745B5@sjceml521-mbs.china.huawei.com>
In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F66B2745B5@sjceml521-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.6.190114
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.19.76.53]
Content-Type: multipart/alternative; boundary="_000_8F2F483190A14561B6E96B9C776CC9BBciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.144, xch-rtp-004.cisco.com
X-Outbound-Node: rcdn-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/chtKCQKnJwT-vBR2IB8bS5v8e30>
Subject: Re: [bess] Last call comment to draft-ietf-bess-evpn-inter-subnet-forwarding-05
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 31 Jan 2019 06:10:54 -0000

I am guessing by X and Y, you are referring to VLAN X and Y. Surely the reason that one NVE can do inter-subnet forwarding for X but not Y, is not because of the NVE’s capabilities !!  Again, what it matters is whether a VLAN/BD is configured for inter-subnet forwarding or not. If a VLAN/BD is configured for inter-subnet forwarding on an NVE then it has an IRB interface and the procedure of this draft get exercised. If it doesn’t, then it is good old RFC 7432 or RFC 8365 wrt that NVE and with respect to the centralized L3GW, it is the good old router on the stick which is simply the degenerate case of the distributed GW and doesn’t require any new procedure.

-Ali

From: Linda Dunbar <linda.dunbar@huawei.com>
Date: Wednesday, January 30, 2019 at 7:46 PM
To: Cisco Employee <sajassi@cisco.com>om>, "bess@ietf.org" <bess@ietf.org>
Subject: RE: [bess] Last call comment to draft-ietf-bess-evpn-inter-subnet-forwarding-05

Ali,

It is very possible that One NVE can do inter-subnet forwarding for X, but can’t do inter-subnet forwarding for Y. Therefore, the NVE must have a policy on which Subnets it can forward.
Therefore a NVE cannot behave properly if it doesn’t a policy on which subnets it can forward.

  *   The discussion of policy and mapping them to subnet configuration is outside of the scope of this document.
Linda

From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
Sent: Wednesday, January 30, 2019 8:24 PM
To: Linda Dunbar <linda.dunbar@huawei.com>om>; bess@ietf.org
Subject: Re: [bess] Last call comment to draft-ietf-bess-evpn-inter-subnet-forwarding-05

Hi Linda,

Please refer to my reply inline marked with “AS>”

From: BESS <bess-bounces@ietf.org<mailto:bess-bounces@ietf.org>> on behalf of Linda Dunbar <linda.dunbar@huawei.com<mailto:linda.dunbar@huawei.com>>
Date: Thursday, October 4, 2018 at 9:30 AM
To: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>, "ietf@ietf.org<mailto:ietf@ietf.org>" <ietf@ietf.org<mailto:ietf@ietf.org>>
Subject: [bess] Last call comment to draft-ietf-bess-evpn-inter-subnet-forwarding-05

Ali, et al:

Sorry for the late comments. I remember reviewing/contributing to this draft many years ago. Happy to see it is finally moving to IESG Last Call.

The draft describes the mechanism to allow TSs belonging to different subnets attached to same PE to be communicated by the PE (instead hair pinned to the L3GW). Very good optimization.

However, not every PE has the needed policies for any two subnet communication (that is why the traffic was to be sent to L3GW).. Therefore, the draft needs a section to describe how the PEs determine if it has the needed policies for specific inter subnets communication.
In addition, when subnets are scatted among many different PEs, it requires the L3GW to maintain all the mappings. In Data center when there are many VMs or Containers, the number of mappings for L3GW to maintain is huge (it practically becomes host routing for tens of thousands of VMs or Containers). It doesn’t scale well. Therefore, the mechanism should allow some PEs to maintain some of the mappings, i.e. becoming a designated L3GW for some subnets..

AS> The discussion of policy and mapping them to subnet configuration is outside of the scope of this document. If the subnets are configured in a central GW, then that becomes the traditional DC use case of having a L2-domain terminated by centralized L3GW. This document deals with distributed GW where TS default GW functionality is pushed all the way to the edge of the overlay network  - i.e., to the NVEs.

Cheers,
Ali

If you are willing to accept this comment, I can provide the text on “Inter-subnet communication Policy on PE”.

Thank you.

Linda Dunbar