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

I like and support "draft-ietf-grow-va".
I think "draft-ietf-grow-va" would be one of useful design document/technic for FIB suppression.

Regards,
-Shishio

(2012/11/09 11:27), Ronald Bonica wrote:
> How do folks on the list feel?
>
>                           Ron
>
>
>> -----Original Message-----
>> From: Xuxiaohu [mailto:xuxiaohu@huawei.com]
>> Sent: Thursday, November 08, 2012 4:53 PM
>> To: Ronald Bonica
>> Cc: grow@ietf.org
>> 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
>> ________________________________________
>> 发件人: l3vpn-bounces@ietf.org [l3vpn-bounces@ietf.org] 代表 Yakov
>> Rekhter [yakov@juniper.net]
>> 发送时间: 2012年11月8日 23:17
>> 到: erosen@cisco.com
>> 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
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
>