Subject: Re: [nvo3] call for adoption:draft-narten-nvo3-overlay-problem-statement-02

From: Lizhong Jin <[email-masked]>
Date: Fri, 29 Jun 2012 22:18:21 +0800

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