Subject: [vnrg] Status of the VNRG: Dormant or dead?

From: Martin Stiemerling <[email-masked]>
Date: Wed, 6 Jul 2011 07:39:10 +0000

Dear all,

The subject line may be partly incorrect, but that is my current question: 
Is the VNRG just dormant or has the overall interest in the work of RG passed away?

We had the last meeting at the Beijing IETF meeting and also some lively discussion afterwards. 

One of the areas of discussion was (amongst many others):
- openflow vs. forces
- how forces would fit in virtual networks
- do we need tunnel headers for virtual networks on the wire or not?
- definition of acid tests 

What do you see is important for the RG right now or what is missing?

I'm looking forward to your feedback.

  Martin (as RG co-chair)

[email-masked]

NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014

---

From: Roland Bless <[email-masked]>
Date: Wed, 06 Jul 2011 11:44:09 +0200

Hi Martin,

> Is the VNRG just dormant or has the overall interest in the work of RG passed away?

I think that the interest hasn't passed away, but maybe people were
probably busy with other stuff.

> - how forces would fit in virtual networks

I see both technologies mainly focused on control plane / data plane
separation. This doesn't allow

> - do we need tunnel headers for virtual networks on the wire or not?

That depends on the substrate technology, some allow to embed a "VNet
Tag" to identify different virtual links, e.g., VLAN-Tags in Ethernet
headers.

> - definition of acid tests 

Not only definition of acid tests, but also definition of
terms. For instance, how differ traditional VPNs from Virtual
Networks in the context of network virtualization? IMHO current
VPN solutions concentrate mainly on virtual links, advanced concepts
consider virtual nodes as active elements. How do OpenFlow concepts fit
into the classification?

> What do you see is important for the RG right now or what is missing?

See above, but maybe we should also consider questions such as
what interfaces and protocols are needed for creating inter-provider
virtual networks.

Regards,
 Roland

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 6 Jul 2011 10:27:26 +0000

Hi Roland, 

> -----Original Message-----
> From: Roland Bless [mailto:[email-masked]]
> Sent: Wednesday, July 06, 2011 11:44 AM
> To: Martin Stiemerling
> Cc: [email-masked]
> Subject: Re: [vnrg] Status of the VNRG: Dormant or dead?
> 
> Hi Martin,
> 

That is good to know and what I actually have hoped for.

> separation. This doesn't allow

What doesn't it allow for? The sentence ends very early.

> Tag" to identify different virtual links, e.g., VLAN-Tags in Ethernet headers.

Right, and my usage of the word deader is probably wrong, as there may be other technologies which use a different light color and not a header to distinguish a VN. 

> Not only definition of acid tests, but also definition of terms. For instance,
> how differ traditional VPNs from Virtual Networks in the context of network
> virtualization? IMHO current VPN solutions concentrate mainly on virtual
> links, advanced concepts consider virtual nodes as active elements. How do
> OpenFlow concepts fit into the classification?

True. Especially VPNs have been discussed multiple times, probably writing this up in a note. 

> See above, but maybe we should also consider questions such as what
> interfaces and protocols are needed for creating inter-provider virtual
> networks.

Ok, I see. 

My question wrt the above paragraph: 
Should the RG run the phase of defining terms, concepts and acid tests in parallel to other questions? We emphasized on a strong phased operational model for the RG until now, but I could imagine a more relaxed operational mode. 

Regards,

  Martin

---

From: Roland Bless <[email-masked]>
Date: Wed, 06 Jul 2011 15:09:53 +0200

Hi Martin,

On 06.07.2011 12:27, Martin Stiemerling wrote:
>>> One of the areas of discussion was (amongst many others): -
>>> openflow vs. forces - how forces would fit in virtual networks
>> 
>> I see both technologies mainly focused on control plane / data
>> plane separation. This doesn't allow
> 

Yes, sorry that's the problem if you are multi-tasking and not
proof-reading your mail again before hitting "Send" :-)
I wanted to avoid a long discussion but maybe I can explain
it a little bit more. While OpenFlow clearly creates more flexibility,
it is rather static with its possibilities in the forwarding plane.
Though one can "virtualize" an OpenFlow switch by partitioning the
forwarding rules in a switch in combination with a FlowVisor in the
control plane, I suppose that a substrate node with explicit
virtualization support is more flexible.

>>> - do we need tunnel headers for virtual networks on the wi
> Right, and my usage of the word deader is probably wrong, as there
> may be other technologies which use a different light color and not a
> header to distinguish a VN.

Yes. Various multiplex techniques may exist in the substrate
to implicitly address different virtual links. Then one can probably
omit any explicit header encapsulation. Using a different wave length
for a new virtual link is clearly one such mechanism.

> My question wrt the above paragraph: Should the RG run the phase of
> defining terms, concepts and acid tests in parallel to other
> questions? We emphasized on a strong phased operational model for the
> RG until now, but I could imagine a more relaxed operational mode.

I think that parallel activities are not a real problem.
Maybe it's sometimes difficult to discuss things if terminology
isn't agreed upon, but that may also cause synergies, revealing what
concepts or terms are unclear and need more discussion.

Regards,
 Roland

---

From: Joe Touch <[email-masked]>
Date: Wed, 06 Jul 2011 08:51:44 -0700

Hi, all,

(speaking as an individual participant)

On 7/6/2011 2:44 AM, Roland Bless wrote:
...
> separation.

I agree, and don't see either as particularly relevant to VNs. They're 
implementation issues, AFAICT. The more relevant technology to me is 
router virtualization.

> Tag" to identify different virtual links, e.g., VLAN-Tags in Ethernet

Again, this is an implementation issue. I would expect some sort of 
indicator of VN, which can be buried inside an existing header or can 
require an additional header.

> consider virtual nodes as active elements.

IMO, a VPN extends an existing network to add a new node, or ties two 
existing networks together, i.e., it's a way to add a single private 
link to a new node.

Further, VPN nodes are always a member of exactly one VPN.

A PPVPN is a network provided by another party (the provider) so that 
users can join it via basically conventional VPN methods.

I don't think of VPNs as addressing either link or router multi-use, either.

None of this is true of VNs, IMO - a VN is a complete E2E network, can 
coexist with many other VNs (even to the same endpoint nodes), etc.

 > How do OpenFlow concepts fit
> into the classification?

IMO, Openflow is a tool; it does not define a network architecture. It 
can be useful in moving some network issues elsewhere (e.g., allowing a 
non-VPN capable node to join a VPN, or helping to implement router 
virtualization outside a router that doesn't support it). I don't see 
Openflow as anything other than one of many tools here - and one I've 
never needed to develop VNs (if others do, I'd be glad to hear why).

> what interfaces and protocols are needed for creating inter-provider

That seems to presume we know what an intra-provider VN is, and I'm not 
sure we're all on a single page there... ;-)

Joe

---

From: Lou Berger <[email-masked]>
Date: Wed, 06 Jul 2011 12:49:29 -0400

Joe,
	I really like & agree with much of what you say, particularly WRT
openflow, forces, and VPNs.

I think some potentially interesting topics for discussion would be:
- the differences (in requirements) between a VN and an overlay network
  (VPNs are just one type of overlay network after all),
- the requirements for the control interface at the VN/overlay-provider
boundary.

Lou

On 7/6/2011 11:51 AM, Joe Touch wrote:
> _______________________________________________
> vnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/vnrg
> 
> 
> 
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 06 Jul 2011 10:14:05 -0700

Hi, Lou,

On 7/6/2011 9:49 AM, Lou Berger wrote:
> Joe,
> 	I really like&  agree with much of what you say, particularly WRT

Well, my view is that a VN is an overlay (just different names). A VPN 
is a *partial* VN or overlay. I don't know of a kind of overlay I'd say 
wasn't a VN - can you give an example?

> - the requirements for the control interface at the VN/overlay-provider

That implies something like a PPVPN - i.e., a partial overlay setup by a 
provider.

IMO, "provider" is a term of economics, not architecture. I do agree 
that the "interface to configure/control a VN" is interesting, but 
that's just 'yet another network management issue'. It seems, AFAICT, to 
be driven more by net mgt than by VN issues.

Joe

---

From: Márcio Melo <[email-masked]>
Date: Wed, 6 Jul 2011 18:33:46 +0100

Lou, all,

I do not agree that VPN's are overlay network's alike. 
On the contrary, you have VPNs L2 and L3. The ones provided by each Network
Providers, on which you need to do the provision and the setup on physical
hardware routers. 

Interesting topics for discussing that I would put effort  on:
"How to scale VNs to the order of Thousands"
"How to switch from VPNs to VNs - What's hanging it up on Network Providers"
"How to manage VNs - Centralized vs Distributed"

Best Regards,
Márcio Melo

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Lou Berger
> Sent: quarta-feira, 6 de Julho de 2011 17:49
> To: Joe Touch
> Cc: [email-masked]

---

From: Lou Berger <[email-masked]>
Date: Wed, 06 Jul 2011 13:43:29 -0400

Joe,

see below

On 7/6/2011 1:14 PM, Joe Touch wrote:
> Well, my view is that a VN is an overlay (just different names). 

I suspect that a VN is a special case of an overlay, e.g., perhaps in
it's dynamic membership/instantiation properties.

> A VPN 

I guess the answer depends on your definition of a VN.  Do you have a
good formal definition handy?  I'd love to see one we can all agree to.
 (Which was sort of the aim of the question.)

> That implies something like a PPVPN - i.e., a partial overlay setup by a 

Not necessarily, there are lots of overlay types and control
protocols/interfaces to support them.  For example MPLS hierarchy and
ethernet vlans are both examples of overlay technologies that can be
dynamically controlled.

> 
> IMO, "provider" is a term of economics, not architecture. 

Okay, that's a legitimate usage.  I was using more generally to cover
the case to refer to include the mechanisms used to instantiate and
transport/support the overlay.  Do you have an alternate term?  The
ITU-T likes the terms client and network...

> I do agree 

I may be biased by my other activities, but I don't see a reason why
this can't also include a control plane based interface.

Lou

---

From: Roland Bless <[email-masked]>
Date: Wed, 06 Jul 2011 19:46:38 +0200

Hi Joe and all,

> implementation issues, AFAICT. The more relevant technology to me is

Yep, agree.

> require an additional header.

Correct, I just provided an example.

> Further, VPN nodes are always a member of exactly one VPN.

Usually, yes, though one can think of VPN concentrators providing
access to several different VPNs

> I don't think of VPNs as addressing either link or router multi-use,

Yep.

> coexist with many other VNs (even to the same endpoint nodes), etc.

Agree.

> never needed to develop VNs (if others do, I'd be glad to hear why).

Agree.

> sure we're all on a single page there... ;-)

Ok, I meant a VN spanning several substrate providers (or to use
4WARD terminology: Infrastructure Providers - InPs) in
contrast to a VN inside a single InP, which can be provided
by using proprietary protocols.

Regards,
 Roland

---

From: Joe Touch <[email-masked]>
Date: Wed, 06 Jul 2011 16:55:08 -0700

Hi Roland,

To wrap up our exchange (I think)...

...
> access to several different VPNs

Oh - yes. But hosts are generally attached to only one VPN at a time. 
VPN concentrators are a lot like virtual machine devices that emulate 
separate VPN "attachment" points. Ultimately, though, every end system 
is a member of only one VPN, which differentiates it from a VN, IMO.

> by using proprietary protocols.

Oh - certainly. A given VPN can be homogeneous or include hereogeneous 
components, and can either be internetworked (as IP goes over multiple 
link layers) or use gateways to translate between clouds (as the old 
Catenet did).

Joe