-----Original Message-----
From: Xuxiaohu [mailto:[email protected]]
Sent: Thursday, November 08, 2012 4:53 PM
To: Ronald Bonica
Cc: [email protected]
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
________________________________________
发件人: [email protected] [[email protected]] 代表 Yakov
Rekhter [[email protected]]
发送时间: 2012年11月8日 23:17
到: [email protected]
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.
