Subject: New IRTF research group on virtual networks (VNRG)

From: Aaron Falk <[email-masked]>
Date: Tue, 16 Feb 2010 14:28:59 -0500

A new IRTF research group on virtual networks has been created.  Charter
included below. 

--aaron
IRTF Chair

-----------------------------------------------------------

Virtual Networks Research Group (VNRG)

      Chairs

Joe Touch [email-masked] <mailto:[email-masked]>
Martin Stiemerling [email-masked] <mailto:[email-masked]>

      Mailing List

The email list is [email-masked] <mailto:[email-masked]>. You need to be a
list member to send mail to the list. To subscribe, visit the VNRG mail
page <http://www.irtf.org/mailman/listinfo/vnrg> or send an email to
[email-masked] <mailto:[email-masked]>.
An archive of the email list is available at VNRG mail archive
<http://www.irtf.org/mail-archive/web/vnrg>.

      Wiki Site

See http://trac.tools.ietf.org/group/irtf/trac/wiki/vnrg.

      Charter

A recent trend in networking is the concurrent use of a single physical
network for multiple variants or instances of networks, e.g., IPv4 and
some experimental protocol suite, or VLANs. These networks, called
Virtual Networks, provide isolation between network instances or types
and support shared use of the same infrastructure for different purposes.

Virtual networks attempt to better utilize networking infrastructure by
reusing individual routers or links (i.e., either physical or logical
networking resource) for multiple concurrent network instances, or to
aggregate multiple such resources to obtain increased capabilities.
These resources can be any network component, including routers, hosts,
links, and services, (e.g., name mapping services). Increased capability
can refer to aggregate capacity provided by bundles of links or groups
of routers, or increased fault tolerance of a cluster of primary and
backup service systems.

Important properties of Virtual Networks (VNs) are i) that each resource
can be used concurrently by multiple VN instances, ii) the clear
isolation of any VN from all others, and iii) abstraction, in which a
given virtual resource (host, link, router, service) need not directly
correspond to its component resources. These properties need to be
supported down to each physical component, such that each router, host,
and link supports concurrence, isolation, and abstraction.

In the network community, "Virtual Networks" is a very broad term,
including running multiple wavelengths over a fiber, MPLS, virtual
routers, and overlay systems. VN technologies are widely used in parts
of the Internet and other IP-based networks, but the community lacks a
common understanding of the impact of virtualized networks on IP
networking, or how VNs are best utilized. As a result, virtualization
has been difficult to integrate across various systems, such as network
operators, vendors, service providers and testbed providers (e.g. GENI,
FEDERICA, etc).

One current challenge with existing VN systems is the development of
incompatible or competing networking techniques in the Internet, causing
deployment issues in the future (or even now). For instance, there are
numerous ways to virtualize routers and their internal resources (e.g.,
multiple, isolated routing and forwarding tables) and to virtualize core
networks (e.g. MPLS, LISP), but end host virtualization has not been
addressed (e.g., beyond the need for virtual interfaces). Few virtual
network systems allow a particular virtual machine in an end host to
control its attachment to a specific private network. The end host
virtualization architecture also determines whether virtualization is
per virtual machine, per process, or per connection -- and this
difference can determine exactly how the end host can participate in
VNs. Similar issues arise for virtual services, virtual links, etc.

The VNRG will consider the whole system of a VN and not only single
components or a limited set of components; we will identify
architectural challenges resulting from VNs, addressing network
management of VNs, and exploring emerging technological and
implementation issues.

Initial set of work items:

    * concepts/background/terminology
    * common parts of VN architectures
    * common problems/challenges in VN
    * descriptions of appropriate uses
    * some solutions (per-problem perhaps)

The RG will initially focus on VNs but at a later stage the RG will also
be open to related topics, such as system virtualization.

      Organization

The Virtual Networks Research Group (VNRG) provides a forum for
interchange of ideas among a group of network researchers with an
interest in network virtualization in the context of the Internet and
also beyond the current Internet.

The VNRG will encourage the organization of the work in smaller design
teams focused on specific areas of research. The design teams will use
the general mailing list in order to allow the broader community to
follow the evolution of their topics.

Most of the communication inside the VNRG will be done through use of
mailing lists, however, the group will hold regular physical meetings at
least once a year in conjunction with IETF meetings. Additional meetings
may be held at IETF or other venues, such as in conjunction with related
conferences and workshops. Related meetings may include research
conferences and workshops, such as ACM CONEXT ReArch, IEEE Globecom
FutureNet, NSF GENI Engineering Conferences, ACM Sigcomm VISA; national
research efforts, such as NSF's Find, Japan's Akari, and the EU's
Trilogy, 4WARD, and Euroview, and related summer schools.

The VNRG will produce Informational and Experimental RFCs in order to
document the activity of the group and to formalize the outcome of the
research topics carried by the group. In addition, such documentation
could become input to IETF working groups. The VNRG will also encourage
prototyping of virtual network technologies to validate this exploration.

      Membership

The VNRG operates in an open fashion (meetings & mailing list).

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 16 Feb 2010 15:50:33 -0500

I would prefer the phrase 'clear logical isolation' to 'clear isolation'.

In my view a network is only 'clearly isolated' if there is separate
hardware as in installations where different colored cables run
through the different networks. I agree that VN-ish type
configurations can be helpful in addition, but it is not going to be
the case that isolation is an automatic security gain.

For example, many folk who outsource their data centers happily
develop networks with the standard firewall/dmz/firewall configuration
and draw up pretty pictures, completely oblivious to the fact that the
outsource provider has a control plane running between all the
machines.

On Tue, Feb 16, 2010 at 2:28 PM, Aaron Falk <[email-masked]> wrote:
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

-- 
-- 
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/