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) 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. 3) What does the true network abstraction mean? 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. 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. 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. 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. 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. 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. Cheers, Lucy
