RE: About the WG adoption of draft-xu-l3vpn-virtual-subnet-fib-reduction-00

Xuxiaohu <xuxiaohu@huawei.com> Wed, 30 July 2014 09:30 UTC

Return-Path: <xuxiaohu@huawei.com>
X-Original-To: l3vpn@ietfa.amsl.com
Delivered-To: l3vpn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43EDB1B2A25 for <l3vpn@ietfa.amsl.com>; Wed, 30 Jul 2014 02:30:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 So9YywB0H_GL for <l3vpn@ietfa.amsl.com>; Wed, 30 Jul 2014 02:30:35 -0700 (PDT)
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 736151B2A5E for <l3vpn@ietf.org>; Wed, 30 Jul 2014 02:30:33 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHS97097; Wed, 30 Jul 2014 09:30:31 +0000 (GMT)
Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 30 Jul 2014 10:30:30 +0100
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Wed, 30 Jul 2014 17:30:26 +0800
From: Xuxiaohu <xuxiaohu@huawei.com>
To: "Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.com>, "l3vpn@ietf.org" <l3vpn@ietf.org>
Subject: RE: About the WG adoption of draft-xu-l3vpn-virtual-subnet-fib-reduction-00
Thread-Topic: About the WG adoption of draft-xu-l3vpn-virtual-subnet-fib-reduction-00
Thread-Index: Ac+rwxWYhfVtX4WJRN+4Ph691FmBRgADXL+AAACoj5AAAC+oAAAACuwwAADW+wAAAA/kEA==
Date: Wed, 30 Jul 2014 09:30:24 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08299C77@NKGEML512-MBS.china.huawei.com>
References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08298798@NKGEML512-MBS.china.huawei.com> <CFFE797B.E5B49%wim.henderickx@alcatel-lucent.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0829882F@NKGEML512-MBS.china.huawei.com> <CFFE7F16.E5BA0%wim.henderickx@alcatel-lucent.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08298853@NKGEML512-MBS.china.huawei.com> <CFFE84EF.E5BC2%wim.henderickx@alcatel-lucent.com>
In-Reply-To: <CFFE84EF.E5BC2%wim.henderickx@alcatel-lucent.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.98.134]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/l3vpn/wEodm3BqHSTBvIgHPxM6TmuEi7M
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn/>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Jul 2014 09:30:39 -0000

Why do you need to distinguish them from each other? In other words, why can't PE routers process the host route to a given VRF loopback address of a remote PE router as a normal remote host route (i.e., on-demand installation)?

Best regards,
Xiaohu

-----Original Message-----
From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] 
Sent: Wednesday, July 30, 2014 5:20 PM
To: Xuxiaohu; l3vpn@ietf.org
Subject: Re: About the WG adoption of draft-xu-l3vpn-virtual-subnet-fib-reduction-00

Why not, if I configure a loopback in the VRF it has to be advertised, this is generic VRF functionality, nothing to do with virtual subnet. I am not talking to the IP address on the virtual subnet interface.
In this case you need to distinguish between host routes and these VRFs.
Using communities is the best way afais.

On 30/07/14 10:59, "Xuxiaohu" <xuxiaohu@huawei.com> wrote:

>Hi Wim,
>
>In the Virtual Subnet context, the host route corresponding to the VRF 
>interface address doesn't need to be advertised.
>
>Best regards,
>Xiaohu
>
>> -----Original Message-----
>> From: Henderickx, Wim (Wim) 
>> [mailto:wim.henderickx@alcatel-lucent.com]
>> Sent: Wednesday, July 30, 2014 4:55 PM
>> To: Xuxiaohu; l3vpn@ietf.org
>> Subject: Re: About the WG adoption of
>> draft-xu-l3vpn-virtual-subnet-fib-reduction-00
>> 
>> Real loopbacks. E.g. A loopback /32 or /128 configured in the VRF
>> 
>> On 30/07/14 10:52, "Xuxiaohu" <xuxiaohu@huawei.com> wrote:
>> 
>> >Hi Wim,
>> >
>> >Did you mean PE's loopback addresses by "real loopbacks"?
>> >
>> >Best regards,
>> >Xiaohu
>> >
>> >> -----Original Message-----
>> >> From: Henderickx, Wim (Wim)
>> >> [mailto:wim.henderickx@alcatel-lucent.com]
>> >> Sent: Wednesday, July 30, 2014 4:31 PM
>> >> To: Xuxiaohu; l3vpn@ietf.org
>> >> Subject: Re: About the WG adoption of
>> >> draft-xu-l3vpn-virtual-subnet-fib-reduction-00
>> >>
>> >> What I would like to see is a way to identify the host routes 
>> >>since there are 2
>> >> levels: real loopbacks that need to be installed by default and 
>> >>real host routes  that can be installed on demand. It would be good 
>> >>to show how the control  plane could distinguish them using 
>> >>communities or the likes.
>> >>
>> >> On 30/07/14 08:54, "Xuxiaohu" <xuxiaohu@huawei.com> wrote:
>> >>
>> >> >Hi all,
>> >> >
>> >> >Virtual Subnet
>> >> >(http://tools.ietf.org/html/draft-ietf-l3vpn-virtual-subnet) is 
>> >> >intended for building L3 network virtualization overlays within 
>> >> >and/or across data centers. Since a subnet is extended across 
>> >> >multiple PE routers, CE host routes need to be exchanged among PE 
>> >> >routers. As a result, the forwarding table size of PE routers 
>> >> >(e.g., some old ToR
>> >> >switches) may become a big concern in large-scale data center 
>> >> >environments. In fact, some folks had already expressed their 
>> >> >concerns about this potential FIB scaling issue during the WG 
>> >> >adoption poll of
>> >>the Virtual
>> >> Subnet draft.
>> >> >
>> >> >As CE host routes may still need to be maintained on the control 
>> >> >plane of PE routers in some cases (e.g.. MVPN scenario), this 
>> >> >draft 
>> >> >(http://tools.ietf.org/html/draft-xu-l3vpn-virtual-subnet-fib-red
>> >> >uct
>> >> >ion
>> >> >-00
>> >> >) proposes a very simple mechanism for reducing the FIB size of 
>> >> >PE routers without any change to the RIB and even the routing table.
>> >> >
>> >> >During the L3VPN WG session at Toronto, many people had expressed 
>> >> >their supports for the WG adoption of this work (Thanks a lot for 
>> >> >your supports). However, there are still a few people who are not 
>> >> >in favor of the WG adoption. According to WG co-chairs' 
>> >> >suggestion, I would like to request those opposers to explain 
>> >> >their reasons so that we could further improve the draft if possible.
>> >> >
>> >> >Best regards,
>> >> >Xiaohu (on behalf of all co-authors)
>> >> >
>> >
>