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

[Ronald Bonica <[e-mail]>]

Xiaohu,

Since these drafts have been dormant for so long, and since there was so little discussion of them when they were active, we should determine whether there is currently any interest in them.

I invite you to raise that question on this mailing list.

                                              Ron


> -----Original Message-----
> From: Xuxiaohu [mailto:[e-mail]]
> Sent: Thursday, November 15, 2012 5:14 AM
> To: Ronald Bonica
> Cc: [e-mail]
> Subject: re: Wake up two sleeping VA drafts?//: Last Call comments on
> draft-ietf-l3vpn-virtual-hub
> 
> > -----邮件原件-----
> > 发件人: 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
> > > > > Eric> attached to V-hub2.  V-hub1 will receive an S-PMSI A-D
> > > > > Eric> route matching
> > > > > Eric> (S,G) from V-hub2.  V-hub1 then modifies this A-D route
> > > > > Eric> and forwards it to V-spoke1.  V-hub1 could use this route
> > > > > Eric> to identify the P-tunnel originating at V-hub2, thereby
> > > > instructing
> > > > > Eric> V-spoke1 to join V-hub2's tunnel directly.  Then V-hub1
> > > > > Eric> would not be in the data path from S to R, but it would
> > > > > Eric> participate
> > > > in
> > > > > Eric> the control plane.  Wouldn't this meet all the
> > > > > Eric> requirements of the V-hub/V-spoke architecture, while
> > > > > Eric> producing a more optimal path for multicast data, and
> > > > > Eric> 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.