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

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Mon, 2 Jul 2012 17:33:11 +0000

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