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) > >> >>> >> > > >> >>> > > >> >> > >> > > >
