Hi Lucy, Thanks for your review and comments. Please see my comments in-line.
From: Lucy yong <[email protected]<mailto:[email protected]>> Date: Wednesday, October 31, 2012 8:40 AM To: Luyuan Fang <[email protected]<mailto:[email protected]>>, "David Ward (wardd)" <[email protected]<mailto:[email protected]>>, Rex Fernando <[email protected]<mailto:[email protected]>>, Maria Napierala <[email protected]<mailto:[email protected]>>, Nabil Bitar <[email protected]<mailto:[email protected]>>, "Dhananjaya Rao (dhrao)" <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: comment on draft-fang-l3vpn-virtual-pe-framework-01 Hi Co-authors on this draft, I read the document and have some comments and suggestions. 1) The intention of the draft is to extend L3VPN PE to a vPE on end devices in DC. We need to distinct about two cases clearly in the framework, one is that a L3VPN applies to intra DC; another is a L3VPN in DC connecting L3VPN in WAN which connects to Enterprise site. We can fully describe vPE function in the first case. the second case is about L3VPN interworking across different underlying networks, which is orthogonal to vPE functions. The draft seems mix two together. In the nvo3 use case draft, we have clearly described two use cases. (draft-mity-nov3-use-case-04) [LF] vPE can be in any network or compute devices. The following was presented in Atlanta IETF 85: Virtual PE (vPE): A PE software instance which can reside in any network or compute devices. A common place for vPE can be a service network end device, e.g., a server which supports multiple client/application Virtual Machines (VMs), or a Top-of-Rack switch (ToR) in the Data Center. Another example can be a service node in a 3GPP network. https://datatracker.ietf.org/meeting/85/materials.html (under Routing/L3VPN). We are updating our draft to make this clear. 2) Text for the key requirement in section 1.2 : 3) Support end-to-end L3VPN connectivity, e.g. L3VPN can start from a service network end device, connect to a corresponding L3VPN in the WAN, and terminate in another service network end device. Not sure why this is the key requirement. If this is to allow end-to-end L3VPN span across multiple DC sites, DC providers may prefer to use WAN to interconnect DC underlying networks first. Then they can create end-to-end L3VPN (overlay) without WAN operator interferes. This is, in turn, to become the first case in two case mentioned in the first comment. IMO: the key requirements is to support case 1 and case 2 in my first comments. [LF] Overlay without WAN operator's/SPs' involvement is not these SPs' interest. 3) What does the true network abstraction mean? [LF] The text in our draft is "true network virtualization and network abstraction." We can put a comma before "and" to avoid confusion. 4) The third paragraph in section 2.1. comment: if vPE allows L3VPN control plane and forwarding function residing on different physical devices, a protocol is necessary between control plane and forwarding entity. This is a significant change for L3VPN PE function. The draft should point out. [LF] No, vPE does not change L3VPN function definitions, though it has impact to device implementation. We can point this out explicitly. The protocols used between control plane and the forwarder can be existing IETF protocols, for example, end-system draft used XMPP. The VPN functions from the user point of view are not changed. 5) The fourth paragraph in section 2.1. Comment: When vPE and VM on one end device, it simplifies the control plane and data plane functions between PE and CE in RFC4364. The draft should clarity that. [LF] It is implementation matter. Think the L3VPN forwarder sitting on a server as a vitalized linecard somewhere away from the main chassis. And, vPE is a virtualized PE, not a CE. 6) Since we need to decouple the underlying network and the overlay network, i.e. end-to-end L3VPN in this document, modeling a virtualized service network in figure 1 to include Gateway PE, Transport Device and vPE in end device is misleading. The virtualized service network should not include Transport device at all. [LF] L3VPN is an overlay technology, PE/ASBR/RR are all components of L3VPN. Transporting L3VPN packets involves transport LSP (labeled switched path built by using LDP, or RSVP-TE, or MPLSoIP/GRE, etc.). Try not to think the service provided directly by SP WAN networks are not virtual services, they are, and they have existed for a long time. 7) Again, this model should be generic to show that a virtualized service network may include vPEs, PE, or Gateway PE to cover both case 1 and case 2 in my first comment. 8) Again, this model architecture should separate DC physical network and DC virtualized service network like the nvo3 architecture model in the nvo3 framework draft. This will let you describe a WAN L3VPN that may connect to DC underlying network and DC virtualized service network. Please see the draft-hy-nvo3-vpn-gap-analysis draft. [LF] L3VPN is a mature technology, not at the same development stage as nvo3 where Framework/Requirements for CP/DP/MP req. are still being defined, and many folks in nvo3 are trying to learn from each other on the technologies they were not familiar with. In contrast, making extension to L3VPN solutions is just a continued effort, simple as that. 9) If vPE can reside on different physical devices as described in the draft, using a VRF block to describe the VPN entity on a vPE is not proper because you can’t split them further. So Figure 2 need to separate the VRF into two entities and describe that two entities may be on one end device or may on separated devices. IMO: this is significant different from the L3VPN in RFC4364. 10) Figure 3 can only express option A in RFC4364. Option B does not use gateway PE, it only uses ASBR. ASBR is very different from a PE. Although in option B, L3VPN control plane can advertise the VPN routes from a PE in an AS to the PE in another AS. It does not mean that the P nodes in an AS know how to route to the PE in another AS. This will be an issue when use IP GRE tunnels. To use MPLS LSP tunnel, option B requires pre-build MPLS LSP tunnel between two PEs that belong to different ASes, which requires two SPs pre-provisioning process that may not apply to here. The framework need to clarify that. In addition, WAN may use MPLS LSP tunnel and DC may use IP based tunnel. [LF] Many experts corrected this already. We deployed Option B in Jan. 2003 when I was working in AT&T at the time. And we worked/deployed all three options in the field. L3VPN WG is long established WG, so our draft does not provide intro. to PE/ASBR/RR, nor how each Inter-AS option works. Here is some quick recap on Inter-AS options: 1) Option A: use back-to-back VRFs, the ASBR from one AS is treating the ASBR in the other AS as a CE. 2) Option B: use e-BGP to exchange VPN routes between the ASBRs, these ASBRs still need to maintain VRFs, no IGP info exchange between the ASes. 3) Option C: use e-BGP to exchange VPN routes directly via RRs of the two ASes, no VRFs are needed on ASBRs, IGP info must be exchanged between the ASes. In practice, Option C may be used for Inter-AS connections within a single SP, but it is strongly recommended not to use Option C for Inter-Provider connections because of security concerns. Option B is viewed as more practical in general for DC/Cloud connections by many SPs. 11) In section 3, regarding to Centralized routing controller, it is good to enable SDN approach in L3VPN. However, RFC4364 does not enable SDN approach. This is regardless use of vPE or PE. This is significant change to the L3VPN in my opinion. 12) As the result, the framework contains significant extension or changes to existing L3VPN. We should require the WG recharter to include this pieces first. [LF] That is upto the Chairs/ADs to decide. Personally, I see the this work fit into the current charter quite fine according to the current charter definition. http://datatracker.ietf.org/wg/l3vpn/charter/ Thanks, Luyuan Cheers, Lucy
