Hi Tom and other co-authors,
Glad to see this new version from the united team and within short time. Cheers!
This revision is much better in describing the problem areas and the needs for
network overlays and summary existing technologies.
1) In Abstract
This isolation can be achieved
by assigning one or more virtual networks to each tenant such that
traffic within a virtual network is isolated from traffic in other
virtual networks.
Suggestion:
This isolation can be achieved
by assigning one or more virtual networks to each tenant.
2) In Introduction (page 5)
A key requirement is that each
individual virtual network instance be isolated from other virtual
network instances.
Suggestion:
A key requirement is that each
individual virtual network instance be isolated from other virtual
network instances or may interconnect to another through
controlled points such as a security gateways.
3) In 3.1 (page 9)
Overlays are based on what is commonly known as a "map-and-encap"
architecture. There are three distinct and logically separable
steps:
suggest:
Overlays are based on what is commonly known as a "map-and-encap"
architecture. In packet processing and forwarding, there are three distinct
and logically separable
steps:
4) In 3.1 (page 10)
the original
packet carried within the overlay header can be an Ethernet frame
complete with MAC addresses or just the IP packet.
suggest:
the original
packet carried within the overlay header can be an Ethernet frame
or just the IP packet.
5) In 3.3
In both cases, the implementation of the interconnect functionality
could be distributed across the NVEs,
Comment: first time mention NVE.
suggest:
In both cases, the implementation of the interconnect functionality
could be distributed across the NVEs,[nvo3-frwk]
6) In 3.4
Comment: in overlay design characteristics, "access device" are used in several
places. it is not clear if "access device" means the vswitch on server, or
server itself, or VN edge.
7) In 3.5
To achieve this functionality, a
standardized interaction between the NVE and hypervisor may be
needed, for example in the case where the NVE resides on a separate
device from the VM.
Suggest:
To achieve this functionality, a
standardized interaction between the NVE and hypervisor may be
needed where the NVE resides on a separate
device from the VM.
8) In 3.5 (page 13)
When a VM disconnects, it is
removed from the overlay and the NVE effectively terminates any
tunnels associated with the VM.
Comments: it is possible that more than one VM associate to the same NVE, then
tunnels can't be terminated when a VM is removed. Correct the sentence.
9) in 3.5 (page 14)
In summary, there are three areas of potential work. The first area
concerns the oracle itself and any on-the-wire protocols it needs. A
second area concerns the interaction between the oracle and NVEs.
The third work area concerns protocols associated with attaching and
detaching a VM from a particular virtual network instance. All three
work areas are important to the development of scalable,
interoperable solutions.
Comment: "the first ... it needs", does it mean if it needs or what it needs?
The second and the third area are depended on the answer on the first area.
10) title "4.1. L3 BGP/MPLS IP VPNs" --> "4.1. BGP/MPLS IP VPN"
11) title "4.2. L2 BGP/MPLS IP VPNs" --> "4.2. BGP/MPLS Ethernet VPN"
Comment: existing title misleading.
12) In 4.1
BGP/MPLS IP VPNs are currently deployed in some large enterprise data centers.
Comment: it would be nice to give a citation here
13) Should we also mention VPLS in section 4? it is an overlay and virtual
technology and is widely deployed.
Cheers,
Lucy
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
[email protected]
Sent: Friday, August 10, 2012 12:15 PM
To: [email protected]
Cc: [email protected]
Subject: [nvo3] I-D Action: draft-narten-nvo3-overlay-problem-statement-04.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Virtualization Overlays Working Group
of the IETF.
Title : Problem Statement: Overlays for Network Virtualization
Author(s) : Thomas Narten
David Black
Dinesh Dutt
Luyuan Fang
Eric Gray
Lawrence Kreeger
Maria Napierala
Murari Sridharan
Filename : draft-narten-nvo3-overlay-problem-statement-04.txt
Pages : 21
Date : 2012-08-10
Abstract:
This document describes issues associated with providing multi-
tenancy in large data center networks that require an overlay-based
network virtualization approach to addressing them. A key multi-
tenancy requirement is traffic isolation, so that a tenant's traffic
is not visible to any other tenant. This isolation can be achieved
by assigning one or more virtual networks to each tenant such that
traffic within a virtual network is isolated from traffic in other
virtual networks. The primary functionality required is provisioning
virtual networks, associating a virtual machine's virtual network
interface(s) with the appropriate virtual network, and maintaining
that association as the virtual machine is activated, migrated and/or
deactivated. Use of an overlay-based approach enables scalable
deployment on large network infrastructures.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-narten-nvo3-overlay-problem-statement
There's also a htmlized version available at:
http://tools.ietf.org/html/draft-narten-nvo3-overlay-problem-statement-04
A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-narten-nvo3-overlay-problem-statement-04
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
