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

From: Xuxiaohu <[email-masked]>
Date: Thu, 8 Nov 2012 21:52:47 +0000

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
________________________________________
发件人: [email-masked] [[email-masked]] 代表 Yakov Rekhter [[email-masked]]
发送时间: 2012年11月8日 23:17
到: [email-masked]
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 to
> Eric> V-hub2.  V-hub1 will receive an S-PMSI A-D route matching (S,G) from
> Eric> V-hub2.  V-hub1 then modifies this A-D route and forwards it to
> Eric> V-spoke1.  V-hub1 could use this route to identify the P-tunnel
> Eric> originating at V-hub2, thereby instructing V-spoke1 to join V-hub2's
> Eric> tunnel directly.  Then V-hub1 would not be in the data path from S to
> Eric> R, but it would participate in the control plane.  Wouldn't this meet
> Eric> all the requirements of the V-hub/V-spoke architecture, while producing
> Eric> a more optimal path for multicast data, and eliminating the need to
> Eric> 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.

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 9 Nov 2012 16:27:34 +0000

How do folks on the list feel?

                         Ron

> -----Original Message-----
> From: Xuxiaohu [mailto:[email-masked]]
> Sent: Thursday, November 08, 2012 4:53 PM
> To: Ronald Bonica
> Cc: [email-masked]
> 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!
> 
> 
> > 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?
> >
> 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.

---

From: Shishio Tsuchiya <[email-masked]>
Date: Sat, 10 Nov 2012 00:25:50 -0500

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:
> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow
>

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 15 Nov 2012 10:10:13 +0000

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:[email-masked]]
> 发送时间: 2012年11月10日 0:28
> 收件人: Xuxiaohu
> 抄送: [email-masked]
> 主题: RE: Wake up two sleeping VA drafts?//: Last Call comments on

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 15 Nov 2012 10:14:23 +0000

> -----邮件原件-----
> 发件人: Xuxiaohu
> 发送时间: 2012年11月15日 18:10
> 收件人: 'Ronald Bonica'
> 抄送: [email-masked]
> 主题: re: Wake up two sleeping VA drafts?//: Last Call comments on

Sorry, the above should be: Didn't the WG adoption and the IESG submission of these three drafts already
demonstrate the WG rough consensus?

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 16 Nov 2012 17:40:55 +0000

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

> Sent: Thursday, November 15, 2012 5:14 AM
> To: Ronald Bonica
> Cc: [email-masked]
> Subject: re: Wake up two sleeping VA drafts?//: Last Call comments on
> > 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
> >
> > > -----邮件原件-----
> > > > 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.
> > > >
> > > > 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.
> > > >
> > > > > 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
> > > > 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 ?
> > > >