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]> > To: "NAPIERALA, MARIA H" <[email protected]>, <[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]] *On Behalf > Of *NAPIERALA, MARIA H > *Sent:* Wednesday, June 27, 2012 3:04 PM > *To:* [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]<[email protected]>] > *On Behalf Of *Benson Schliesser (bschlies) > *Sent:* Saturday, June 16, 2012 9:01 PM > *To:* [email protected] > *Cc:* Matthew (Matthew) Bocci; > [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] > https://www.ietf.org/mailman/listinfo/nvo3 > >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
