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

["Henderickx, Wim (Wim)" <[e-mail]>]

In that case you can argue why not do it for all routes as well.

On 30/07/14 11:30, "Xuxiaohu" <[e-mail]> 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:[e-mail]]
>Sent: Wednesday, July 30, 2014 5:20 PM
>To: Xuxiaohu; [e-mail]
>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" <[e-mail]> 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:[e-mail]]
>>> Sent: Wednesday, July 30, 2014 4:55 PM
>>> To: Xuxiaohu; [e-mail]
>>> 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" <[e-mail]> wrote:
>>> 
>>> >Hi Wim,
>>> >
>>> >Did you mean PE's loopback addresses by "real loopbacks"?
>>> >
>>> >Best regards,
>>> >Xiaohu
>>> >
>>> >> -----Original Message-----
>>> >> From: Henderickx, Wim (Wim)
>>> >> [mailto:[e-mail]]
>>> >> Sent: Wednesday, July 30, 2014 4:31 PM
>>> >> To: Xuxiaohu; [e-mail]
>>> >> 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" <[e-mail]> 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)
>>> >> >
>>> >
>>
>