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]] 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-0
2 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
