> -----邮件原件----- > 发件人: Xuxiaohu > 发送时间: 2012年11月15日 18:10 > 收件人: 'Ronald Bonica' > 抄送: [email protected] > 主题: re: Wake up two sleeping VA drafts?//: Last Call comments on > draft-ietf-l3vpn-virtual-hub > > Hi Ron, > > Did the WG adoption and the IESG submission of these three drafts already > demonstrate the WG rough consensus?
Sorry, the above should be: Didn't the WG adoption and the IESG submission of these three drafts already demonstrate the WG rough consensus? > Best regards, > Xiaohu > > > -----邮件原件----- > > 发件人: Ronald Bonica [mailto:[email protected]] > > 发送时间: 2012年11月10日 0:28 > > 收件人: Xuxiaohu > > 抄送: [email protected] > > 主题: RE: Wake up two sleeping VA drafts?//: Last Call comments on > > draft-ietf-l3vpn-virtual-hub > > > > How do folks on the list feel? > > > > Ron > > > > > > > -----Original Message----- > > > From: Xuxiaohu [mailto:[email protected]] > > > Sent: Thursday, November 08, 2012 4:53 PM > > > To: Ronald Bonica > > > Cc: [email protected] > > > Subject: Wake up two sleeping VA drafts?//: Last Call comments on > > > draft-ietf-l3vpn-virtual-hub > > > > > > 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 > > > > Eric> to V-hub2. V-hub1 will receive an S-PMSI A-D route matching > > > > Eric> (S,G) from V-hub2. V-hub1 then modifies this A-D route and > > > > Eric> forwards it to V-spoke1. V-hub1 could use this route to > > > > Eric> identify the P-tunnel originating at V-hub2, thereby > > > instructing > > > > Eric> V-spoke1 to join V-hub2's tunnel directly. Then V-hub1 would > > > > Eric> not be in the data path from S to R, but it would participate > > > in > > > > Eric> the control plane. Wouldn't this meet all the requirements of > > > > Eric> the V-hub/V-spoke architecture, while producing a more optimal > > > > Eric> path for multicast data, and eliminating the need to 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
