Hi Wim, I just want to figure out in which scenario the host route to the VRF interface address of a remote PE router should be FIB-installed by default. If there is a scenario, I agree that your proposal of using communities is the best way.
Best regards, Xiaohu > -----Original Message----- > From: Henderickx, Wim (Wim) [mailto:[email protected]] > Sent: Wednesday, July 30, 2014 5:37 PM > To: Xuxiaohu; [email protected] > Subject: Re: About the WG adoption of > draft-xu-l3vpn-virtual-subnet-fib-reduction-00 > > In that case you can argue why not do it for all routes as well. > > On 30/07/14 11:30, "Xuxiaohu" <[email protected]> wrote: > > >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:[email protected]] > >Sent: Wednesday, July 30, 2014 5:20 PM > >To: Xuxiaohu; [email protected] > >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" <[email protected]> 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:[email protected]] > >>> Sent: Wednesday, July 30, 2014 4:55 PM > >>> To: Xuxiaohu; [email protected] > >>> 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" <[email protected]> wrote: > >>> > >>> >Hi Wim, > >>> > > >>> >Did you mean PE's loopback addresses by "real loopbacks"? > >>> > > >>> >Best regards, > >>> >Xiaohu > >>> > > >>> >> -----Original Message----- > >>> >> From: Henderickx, Wim (Wim) > >>> >> [mailto:[email protected]] > >>> >> Sent: Wednesday, July 30, 2014 4:31 PM > >>> >> To: Xuxiaohu; [email protected] > >>> >> 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" <[email protected]> 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-re > >>> >> >d > >>> >> >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) > >>> >> > > >>> > > >> > >
