[GROW] Wake up two sleeping VA drafts?//: Last Call comments on draft-ietf-l3vpn-virtual-hub

[Xuxiaohu <[e-mail]>]

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
________________________________________
发件人: [e-mail] [[e-mail]] 代表 Yakov Rekhter [[e-mail]]
发送时间: 2012年11月8日 23:17
到: [e-mail]
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.