Hi Ronald, If I remembered correctly, you have said, during the WG last call of three VA draft, that you may reconsider your attitudes towards the two of three VA drafts (draft-ietf-grow-va and draft-ietf-grow-va-auto) in case there were any interests from SPs on the FIB aggregation.
I occasionally noticed that draft-ietf-l3vpn-virtual-hub has just decribed a use case of FIB aggregation and a possible FIB aggregation approach which seems much similar to the VA approach (see the following text quoted from that draft). You may have noticed that most of the co-authors of this draft are from SPs. In addition, there are many concerns with the forwarding table scalability issues in the multi-tenant cloud data center network environments that have been expressed in several NVo3 related drafts. Hence I wonder whether you could please reconsider your attitudes towards the two of three VA related drafts. Many thanks! ************************** 9. Further refinements In some cases a VPN customer may not want to rely solely on an (IP) default route being advertised from a V-spoke to a CE, but may want CEs to receive all the VPN routes (e.g., for the purpose of faster detection of VPN connectivity failures, and activating some backup connectivity). In this case one possible approach would be to install in the V- spoke's data plane only the default route (following the Virtual Hub and Spoke model, as described above), but keep all the VPN-IP routes in the V-spoke's control plane (and thus being able to advertise these routes from the V-spoke to the CEs). Granted, this would not change control plane resource consumption, but would (significantly) reduce resource consumption on the data plane. ***************************** Best regards, Xiaohu ________________________________________ 发件人: [email protected] [[email protected]] 代表 Yakov Rekhter [[email protected]] 发送时间: 2012年11月8日 23:17 到: [email protected] Cc: L3VPN 主题: Re: Last Call comments on draft-ietf-l3vpn-virtual-hub Eric, > I have a number of comments on the virtual-hub draft. Some are minor and/or > editorial, but a number are more substantial. I think these comments need > to be addressed before the draft is submitted for publication. > > I've placed a lot of comments in-line, but let me summarize what I think are > the major issues: I am in the process of addressing your comments. In this e-mail I'd like to focus on one particular one: > Eric> Let's consider the case where the source is at a site attached to > Eric> V-hub2. V-hub1 will receive an S-PMSI A-D route matching (S,G) from > Eric> V-hub2. V-hub1 then modifies this A-D route and forwards it to > Eric> V-spoke1. V-hub1 could use this route to identify the P-tunnel > Eric> originating at V-hub2, thereby instructing V-spoke1 to join V-hub2's > Eric> tunnel directly. Then V-hub1 would not be in the data path from S to > Eric> R, but it would participate in the control plane. Wouldn't this meet > Eric> all the requirements of the V-hub/V-spoke architecture, while producing > Eric> a more optimal path for multicast data, and eliminating the need to > Eric> have the V-hubs splice together any P-tunnels? > > Eric> Was any consideration given to such an alternative? Please note that the procedures specified in the draft assume the ability to perform sender-based RPF, as specified in 9.1.1 of rfc6513. Given that, if one would follow what you outlined above, could you point me to the specific text in 9.1.1 that would enable V-spoke1 to determine that from its own perspective the UMH for (C-S, C-G) is V-hub1 ? Furthermore, your outline above talks about S-PMSI A-D route. How would it work for I-PMSI A-D routes ? Yakov. _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
