Subject: comments and questions on the draft-fang-l3vpn-end-system-requirements-01.txt

From: Lucy yong <[email-masked]>
Date: Fri, 16 Nov 2012 00:23:02 +0000

Hi Maria and Luyuan,

I read through this document. It is well written document. I have some comments and questions as follow.

*         In section 2.2., it requires that in end-system environment,  the PE forwarding function should decouple from PE control function (physically) but does not make any requirement on the interworking between  two functions. Do you expect the proprietary implementation in this interworking is acceptable  or have to be a standardized interworking solution? I suggest mentioning this decoupling also enables some "centralized/distributed"  combined control plane solution, which may fit the DC environment better.

*         Section 3.3 IP subnet support. Could you elaborate how you want to group virtual resources into IP subnets? Do you mean Sp may want the resources that run VoIP on one IP subnet and the resources that run video on another IP subnets regardless where the resources locate?  What does  "user defined IP subnet" mean? Please give an example.

*         Text:
   A collection of virtual resources might provide external or
   internal services. Such collection may serve an external "customer"
   or internal "tenant" to whom a Service Provider provides
   service(s). In MPLS/BGP VPN terminology a collection of virtual
   resources dedicated to a process or application corresponds to a
   VPN.
   -end. The first sentence means cloud service. The resources include compute, storage, network appliance, and networking. It is not clear to me what the second sentence mean?

*         Text: -VM or application end-point should be able to directly access
      multiple VPNs without a need to traverse a gateway. -end.
   In this case, does it use the same IP address or different IP address when accessing different VPNs? Please clarify.

*         In section 5, suggest to add one advantage, it makes IP mobility easier because the decoupling eliminates the physical network limitation in supporting the mobility

*         Text: the virtual service itself must be delivered to an
   end-system such that switching elements connecting the end-system
   to the encap/decap device are not aware of the virtual topology.
-end. This is about local access between CE and PE, right? This is always the case. Do you expect the payload to be encapsulated in local access too? Why state it in this section?

*         Regarding to section 7.1, Do you require that the end system to support LDP and RSVP-TE in order to support the end-system VPN?

*         In Section 8, what is the midpoint router? The first hop router, or gateway router, or any LSR? Describe from one end-system to another end system do not make this clear because PE may be on the end-system or may not.

*         In section 9, what does "abstracting the externally visible network address from ..." mean?

*         In section 10, text:
   The inter-connection of end-system VPNs with traditional VPNs
   requires an integrated control plane and unified orchestration of
   network and end-system resources. -end.
   What does that mean? Do you want to say interworking between traditional control plane in WAN and orchestration system in DC?

*         There is no any requirement on a gateway usage. Do you expect no gateway at all in end system VPN? Do we need NAT, firewall in end system VPN?

*         The document does not use the requirement language to describe the requirement. "MUST", "SHOULD", etc.

Look forward to hearing from you on these.

Cheers,
Lucy