Re: [bess] A comment and question for the draft "draft-ietf-bess-evpn-inter-subnet-forwarding-00"
Haoweiguo <haoweiguo@huawei.com> Tue, 25 November 2014 13:02 UTC
Return-Path: <haoweiguo@huawei.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C174D1A0271 for <bess@ietfa.amsl.com>; Tue, 25 Nov 2014 05:02:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 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] autolearn=ham
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 vk3rd8iqc_cV for <bess@ietfa.amsl.com>; Tue, 25 Nov 2014 05:02:42 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7EB61A026F for <bess@ietf.org>; Tue, 25 Nov 2014 05:02:41 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BPF03197; Tue, 25 Nov 2014 13:02:39 +0000 (GMT)
Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 25 Nov 2014 13:01:49 +0000
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.193]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Tue, 25 Nov 2014 21:01:46 +0800
From: Haoweiguo <haoweiguo@huawei.com>
To: "Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.com>, "bess@ietf.org" <bess@ietf.org>, "sajassi@cisco.com" <sajassi@cisco.com>
Thread-Topic: [bess] A comment and question for the draft "draft-ietf-bess-evpn-inter-subnet-forwarding-00"
Thread-Index: AQHQCJ9L0ixxt+ZqHkGcmnxIjcOU3pxxSvP+
Date: Tue, 25 Nov 2014 13:01:45 +0000
Message-ID: <DD5FC8DE455C3348B94340C0AB5517334F81F4AF@nkgeml501-mbs.china.huawei.com>
References: <D09A2022.10CE3C%wim.henderickx@alcatel-lucent.com>
In-Reply-To: <D09A2022.10CE3C%wim.henderickx@alcatel-lucent.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.135.23.94]
Content-Type: multipart/alternative; boundary="_000_DD5FC8DE455C3348B94340C0AB5517334F81F4AFnkgeml501mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/bess/pmrp0oqqrA5kZz529kjpCbyU-Ss
Subject: Re: [bess] A comment and question for the draft "draft-ietf-bess-evpn-inter-subnet-forwarding-00"
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Tue, 25 Nov 2014 13:02:45 -0000
Hi Wim, Yes, the design has flexibility. But for most scenarios, we don't need this flexibility, we want to more compact encoding method. If all MAC routes advertised from a egress NVE share same NVE MAC and tunnel type, the two BGP Extended Communities carried with each MAC route is redundant, egress NVE only needs advertise its NVE MAC and tunnel type only once. I think we had better provide two alternative solutions, one is for flexibility, another one is for compactness. Depending on different scenarios, the vendors can choose one for implementation. Thanks weiguo ________________________________ From: Henderickx, Wim (Wim) [wim.henderickx@alcatel-lucent.com] Sent: Tuesday, November 25, 2014 19:02 To: Haoweiguo; bess@ietf.org; sajassi@cisco.com Subject: Re: [bess] A comment and question for the draft "draft-ietf-bess-evpn-inter-subnet-forwarding-00" The reason we did this is providing the most flexibility because depending on the use case you need one and not the other. Hence we optimised for flexibility. From: Haoweiguo <haoweiguo@huawei.com<mailto:haoweiguo@huawei.com>> Date: Tuesday 25 November 2014 10:21 To: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>, sajassi <sajassi@cisco.com<mailto:sajassi@cisco.com>> Subject: [bess] A comment and question for the draft "draft-ietf-bess-evpn-inter-subnet-forwarding-00" Hi Ali and other Co-authors, In the EVPN IRB draft, Route Type-2 is used to advertise TS's MAC and IP. Two BGP Extended Communities are carried with each RT-2 route. The first community carries tunnel type, the second community carries NVE MAC. In normal case, all RT-2 routes from a remote NVE share same NVE MAC, so in this case the Route information encoding isn't compact. So a new compact encoding method is introduced as follows: 1. Add tunnel type field in Route Type-2. 2. Introduce a new Route Type to exclusively advertise tunnel type,NVE MAC and L3 VN ID. 3. Ingress NVEs correlate the new Type Route and RT-2 routes advertised from egress NVE to get the NVO3 encapsulation information for inter-subnet IP traffic forwarding. Maybe there are other more compact methods. I would like to hear your co-authors opinion on this point. Thanks weiguo
- [bess] A comment and question for the draft "draf… Haoweiguo
- Re: [bess] A comment and question for the draft "… Henderickx, Wim (Wim)
- Re: [bess] A comment and question for the draft "… Haoweiguo
- Re: [bess] A comment and question for the draft "… Rabadan, Jorge (Jorge)
- Re: [bess] A comment and question for the draft "… John E Drake
- Re: [bess] A comment and question for the draft "… John E Drake
- Re: [bess] A comment and question for the draft "… Henderickx, Wim (Wim)
- Re: [bess] A comment and question for the draft "… Haoweiguo