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
