The question is than do we want to standardise this community? On 31/07/14 09:24, "Xuxiaohu" <[email protected]> wrote:
>Hi Wim, > >Great. How about adding the following text somewhere in the draft: > >"If one or more particular remote host routes need to be installed by >default for whatever reasons, the best way to realize such goal is to >attach a special extended community attribute to those particular host >routes by originating PE routers or route reflectors. Upon receiving any >host routes attached with the above extended community attribute, non-APR >PE routers would install them by default" > >Of course, it would be much appreciated if you could provide some text. > >Best regards, >Xiaohu > >> -----Original Message----- >> From: Henderickx, Wim (Wim) [mailto:[email protected]] >> Sent: Wednesday, July 30, 2014 6:11 PM >> To: Xuxiaohu; [email protected] >> Subject: Re: About the WG adoption of >> draft-xu-l3vpn-virtual-subnet-fib-reduction-00 >> >> See right now there is /32 or /128 routes which can come from hosts in >>virtual >> subnet/CE-PE protocol/static routes/loopbacks/etc and to figure out the >>origin >> you have very little means doing so. So if an operator wants to >>distinguish the >> installation by default in the FIB it would be good to tag the origin >>and he can >> than decide based on local policy what to do. I believe it is a good >>practice and >> should be described in the draft. >> >> This is what I meant to say >> >> On 30/07/14 11:48, "Xuxiaohu" <[email protected]> wrote: >> >> >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) >> >> >>> >> > >> >> >>> > >> >> >> >> >> > >> > >
