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

Linda Dunbar <linda.dunbar@huawei.com> Thu, 04 October 2018 16:30 UTC

Return-Path: <linda.dunbar@huawei.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 29D46130DC2; Thu, 4 Oct 2018 09:30:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id BKcHDfspU6VH; Thu, 4 Oct 2018 09:30:48 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com []) (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 8BAB5130DE4; Thu, 4 Oct 2018 09:30:48 -0700 (PDT)
Received: from lhreml704-cah.china.huawei.com (unknown []) by Forcepoint Email with ESMTP id 47CBFF4A1B7D8; Thu, 4 Oct 2018 17:30:42 +0100 (IST)
Received: from SJCEML701-CHM.china.huawei.com ( by lhreml704-cah.china.huawei.com ( with Microsoft SMTP Server (TLS) id 14.3.399.0; Thu, 4 Oct 2018 17:30:44 +0100
Received: from SJCEML521-MBS.china.huawei.com ([]) by SJCEML701-CHM.china.huawei.com ([]) with mapi id 14.03.0415.000; Thu, 4 Oct 2018 09:30:38 -0700
From: Linda Dunbar <linda.dunbar@huawei.com>
To: "bess@ietf.org" <bess@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Thread-Topic: Last call comment to draft-ietf-bess-evpn-inter-subnet-forwarding-05
Thread-Index: AdRb/g9pT37QapfuQM+OVrJwKjW0XA==
Date: Thu, 04 Oct 2018 16:30:37 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F66B14EDD0@sjceml521-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F66B14EDD0sjceml521mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/4fMJYHpQa9seG93EZagSotxRwyQ>
Subject: [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, 04 Oct 2018 16:30:50 -0000

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.

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

Thank you.

Linda Dunbar