Lizhong, Thanks for your comments.
Em, certainly not readers misunderstanding/misinterpretation... VRF-Lite is not IP/BGP VPN general approach, it should not be confused. May be the authors can help to clarify what was the intent, if still necessary. If VRF-Lite was really the case, then 4364 main stream VPN is totally missed. Regarding merging. We very much like the idea at the concept level, we are willing. But we see it is rather difficult in practice. As just discussed by Joel and Rob, is it wise to boil all drastically diff. problems a into a single pb statement? same goes with req. and fw doc...? It is true that L2 VN and L3 VN can share many common protocol stack, but they are fundamentally different in most cases. If one starts from what the design objective is, what services much be supported (all IP or legacy L2), what the scale target is, operational complexity/cost impact,... the choice of L3 or L2 may have to be one way or another in many cases. Luyuan From: Lizhong Jin [mailto:[email protected]] Sent: Friday, June 29, 2012 10:18 AM To: [email protected] Cc: Luyuan Fang (lufang); [email protected] Subject: Re: [nvo3] call for adoption:draft-narten-nvo3-overlay-problem-statement-02 I believe there are some concept misunderstanding when interpreting draft-narten-nvo3-overlay-problem-statement-02 section 3.1. The VRF in the problem statement refers to VRF-Lite, which is already deployed in datacenter hop by hop. In that case, it requres running separate routing instance for each VRF on every hop, and no MP-BGP and tunnel required. The VRF or VPN with reference of RFC4364 is the one that widely deployed in WAN, with MP-BGP signaling. If I am wrong, please the authors help to correct. Section 3.1 needs some re-wording to make it clear. For many guys, the VRF concept means RFC4364, not VRF-Lite. I still think draft-narten and draft-fang could be merged, and I don't expect to see two totally different data plane and control plane solution for L2 VN and L3 VN in future. I believe L2 VN and L3 VN could share many things, e.g, protocol stack definition. Thanks Lizhong ---------- Forwarded message ---------- From: "Luyuan Fang (lufang)" <[email protected]<mailto:[email protected]>> To: "NAPIERALA, MARIA H" <[email protected]<mailto:[email protected]>>, <[email protected]<mailto:[email protected]>> Cc: Date: Fri, 29 Jun 2012 01:43:05 -0500 Subject: Re: [nvo3] call for adoption:draft-narten-nvo3-overlay-problem-statement-02 I share similar concerns as Maria, and Pedro, Dimitri, John, Lucy, Yakov... I'm afraid I cannot support this draft as WG doc at this time. Here are some comments. Section 1. Introduction "How a virtual network is implemented does not matter to the tenant. It could be a pure routed network, a pure bridged network or a combination of bridged and routed networks..." That is not quite true. L3 or L2 could matter in some cases. E.g. Cases need L3: - LTE DC - Some IP applications do not survive with L2 (Microsoft presented this at Carrier Cloud Summit last week) - Very large scale DC. Recent examples of large scale L3 DCs: Amazon EC2, Microsoft Azure, Google, Yahoo... Cases need L2: Must support existing L2 services. A large numbers of DCs will continue require L2 for a long time. 3.1. Limitations of Existing Virtual Network Models L3 VPN (RFC 4364) descriptions in this section are mostly not correct.. " VRF's are a pure routing construct and do not have end-to-end significance in the sense that the data plane carries a VRF indicator on an end-to-end basis." That is why L3VPN (RFC 4364) scales. Why is this an issue? Dimitri asked the same. " Instead, the VRF is derived at each hop using a combination of incoming interface and some information in the frame (e.g., local VLAN tag)." Not true, and very confusing text. VRFs are configured on PEs, they only exists on the VPN terminating point - PE. P routers have no knowledge of VPNs, no VRF on P. "Furthermore, the VRF model has typically assumed that a separate control plane governs the population of the forwarding table within that VRF." Not true, no separate control planes. Also, VRFs can be used to support multi-tenancy, provide routing separation, as Dimitri already pointed out. "But VPN approaches have traditionally been deployed across WANs and have not seen widespread deployment within enterprise data centers." "VPN approaches ... have not seen widespread deployment within enterprise data centers" does not mean that VPN approaches are not suitable for Carrier Cloud data centers. And the scope of NVO3 is not limited to enterprises. "They are not necessarily seen as supporting the characteristics outlined in Section 2.7." Why not? I think Pedro already explained, not to repeat here. Give most text on VPN discussion is not accurate and very confusing. I'd suggest to remove them. draft-fang-vpn4dc-problem-statements covers this topic. Thanks, Luyuan From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of NAPIERALA, MARIA H Sent: Wednesday, June 27, 2012 3:04 PM To: [email protected]<mailto:[email protected]> Subject: Re: [nvo3] call for adoption:draft-narten-nvo3-overlay-problem-statement-02 I cannot support this draft in its current form, primarily because of the following assessment regarding IP VPNs: Section 3.1: "There are number of VPN approaches that provide some of the desired semantics of virtual networks (e.g., [RFC4364]). But VPN approaches have traditionally been deployed across WANs and have not seen widespread deployment within enterprise data centers. They are not necessarily seen as supporting the characteristics outlined in Section 2.7." The "characteristics" listed in section 2.7 are supported by IP VPNs. The number 4 "characteristic" in section 2.7 (which is quite vague IMO) would not be met by number of proposals (listed in section 4) since they require new software. Hence, the IP VPN description is clearly out of place in section 3.1. Another comment that I want to make is on section 3.3: Section 3.3: "From an architectural perspective, one can view the address mapping dissemination problem as having two distinct and separable components. The first component consists of a back-end "oracle" that is responsible for distributing and maintaining the mapping information for the entire overlay system. The second component consists of the on-the-wire protocols an NVE uses when interacting with the oracle." This is exactly what marques-end-systems proposes. I think it would be important (for completeness) to refer to this draft in draft-narten-nvo3-overlay-problem-statement-02. Thanks. Maria From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Benson Schliesser (bschlies) Sent: Saturday, June 16, 2012 9:01 PM To: [email protected]<mailto:[email protected]> Cc: Matthew (Matthew) Bocci; [email protected]<mailto:[email protected]> Subject: [nvo3] call for adoption:draft-narten-nvo3-overlay-problem-statement-02 Dear NVO3 Participants - This message begins a two week Call for Adoption of http://tools.ietf.org/html/draft-narten-nvo3-overlay-problem-statement-02 by the NVO3 working group, ending on 30-June-2012. Please respond to the NVO3 mailing list with any statements of approval or disapproval, along with any additional comments that might explain your position. Also, if any NVO3 participant is aware of IPR associated with this draft, please inform the mailing list and/or the NVO3 chairs. Thanks, -Benson & Matthew _______________________________________________ nvo3 mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
