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

[Xuxiaohu <[e-mail]>]

Hi Ron,

Did the WG adoption and the IESG submission of these three drafts already demonstrate the WG rough consensus?

Best regards,
Xiaohu

> -----邮件原件-----
> 发件人: Ronald Bonica [mailto:[e-mail]]
> 发送时间: 2012年11月10日 0:28
> 收件人: Xuxiaohu
> 抄送: [e-mail]
> 主题: 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:[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.