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

[Ronald Bonica <[e-mail]>]

How do folks on the list feel?

                         Ron


> -----Original Message-----
> From: Xuxiaohu [mailto:[e-mail]]
> Sent: Thursday, November 08, 2012 4:53 PM
> To: Ronald Bonica
> Cc: [e-mail]
> 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
> ________________________________________
> 发件人: [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
> > 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.