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

[Xuxiaohu <[e-mail]>]

> -----邮件原件-----
> 发件人: Xuxiaohu
> 发送时间: 2012年11月15日 18:10
> 收件人: 'Ronald Bonica'
> 抄送: [e-mail]
> 主题: re: Wake up two sleeping VA drafts?//: Last Call comments on
> draft-ietf-l3vpn-virtual-hub
> 
> Hi Ron,
> 
> Did the WG adoption and the IESG submission of these three drafts already
> demonstrate the WG rough consensus?

Sorry, the above should be: Didn't 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.