Subject: [nvo3] Fwd: New Version Notification for draft-ashwood-nvo3-oam-requirements-02.txt

From: "Chenhao (philips)" <[email-masked]>
Date: Fri, 20 Mar 2015 01:30:09 +0000

Sorry for the late notification. We have updated the oam-req draft that dicusses the oam requirements of nvo3. The major revision includes the addition of the Continuity Check and Live Traffic Monitoring. Any comments are welcome.

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 
发送时间: 2015年3月9日 15:58
收件人: Masahiro Daikoku; Chenhao (philips); Tina TSOU; AshwoodsmithPeter; Ram Krishnan; Ali Sajassi; Tina TSOU; Ram (Ramki) Krishnan; Chenhao (philips); Mohamed Boucadair; Ali Sajassi; Xialiang (Frank); Mohamed Boucadair; Christian Jacquenet; Anoop Ghanwani; Masahiro Daikoku; Anoop Ghanwani; Rangaraju Iyengar; Rangaraju Iyengar; Christian Jacquenet; AshwoodsmithPeter; Xialiang (Frank)
主题: New Version Notification for draft-ashwood-nvo3-oam-requirements-02.txt

A new version of I-D, draft-ashwood-nvo3-oam-requirements-02.txt
has been successfully submitted by Hao Chen and posted to the IETF repository.

Name:		draft-ashwood-nvo3-oam-requirements
Revision:	02
Title:		NVO3 Operations, Administration, and Maintenance Requirements
Document date:	2015-03-08
Group:		Individual Submission
Pages:		21
URL:            http://www.ietf.org/internet-drafts/draft-ashwood-nvo3-oam-requirements-02.txt
Status:         https://datatracker.ietf.org/doc/draft-ashwood-nvo3-oam-requirements/
Htmlized:       http://tools.ietf.org/html/draft-ashwood-nvo3-oam-requirements-02
Diff:           http://www.ietf.org/rfcdiff?url2=draft-ashwood-nvo3-oam-requirements-02

Abstract:
   This document provides framework and requirements for Network
   Virtualization Overlay (NVO3) Operations, Administration, and
   Maintenance (OAM).  This document for the most part gathers
   requirements from existing IETF drafts and RFCs which have already
   extensively studied this subject for different data planes and
   layering.  As a result this draft is high level and broad.  We begin
   to ask which are truly required for NVO3 and expect the list to be
   narrowed by the working group as subsequent versions of this draft
   are created.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: [email-masked]
Date: Fri, 20 Mar 2015 16:12:59 +0800

Dear ALL,
About the automatic VN services provisioning requirements, we’ve 
submitted a draft draft-gu-nvo3-auto-provisioning-reqs-00(and -01 with 
minor modification) to NVO3 website. We've received e-mail and oral 
responses from some experts. Their initial impression are the goal maybe 
somehow too ambitious, because of the broad domain of NVO3 VN service 
automation, including VM automatic creation and interaction with 
Virtualization orchestration system etc., but, they agree the requirements 
are good for the VN service providing. 
Generally speaking, automatic service providing may be good for every 
service if it’s possible, because of: 1), quick service provision to 
customer and/or shorten the time to market; 2), less manual configuration 
and lower operation cost; 3), eliminate the possibility of manual 
configuration errors, and so on.
So, we initiate this discussion, hope, in a narrower but still practical 
and useful scope to implement NVO3 automatic VN services provisioning.
First, we need to clarify what VN is and what kind of VN shall be 
supported in NVO3, then we will show the VN can be implemented by two 
different mechanism, in the scope of NVO3. 
For what kinds of VN shall be supported, we can obtain the related 
information from the draft-ietf-nvo3-use-case-05, it includes many kinds 
of VN, we summary them as following:
1), Virtual Network in DC (Section 2);
2), Virtual Network accessed by enterprise network through secure Gateway 
(Section 3.1);
3), Virtual Network accessed by enterprise network through VPN/PE (Section 
3.2);
4), Multiple/Multi-tier Virtual Networks (Section 4.1);
5), Multiple Virtual Networks connected by other Virtual Network (Section 
4.2);
6), Multiple Virtual Networks accessed by enterprise network and Internet 
through secure Gateway (Section 4.3).
In all these typical usage scenarios, the VN can be abstracted as basic 
VN(s) and the Gateway(s). The basic VN consists of some VMs which connect 
to NVE and multiple NVE connect to each other by underlay network in one 
data center site. And the gateway may be any one or combination of NAT, 
firewall, secure gateway, load balancer, etc.
For virtual network automatic provisioning, if the basic VN(s) and the 
Gateway(s) can be automatically created(and automatically connected) then 
the VN can be automatic provided.
For Gateway automatic provisioning, we already know that the firewall or 
NAT or Gateway can be virtualized to support lots of virtual devices on 
these devices, so we can define some interface to distribute the automatic 
creation command to these devices to realize the gateway automatic 
provision. 
One method is, it can be done or supported by using the NVE-NVA protocol, 
because the gateway and the NVE can be resided in the same datacenter 
gateway generally. Please note that this may need more investigation and 
may be out of the NVO3 scope. 
For basic VN automatic creation, we have proposed the NVE auto-discovery 
protocol to support VM automatic join the VN. [For simplicity, and it’s 
reasonable, we assume that VM is prepared by Hypervisor and is ready been 
configured with some basic parameters such as MAC address and/or IP 
address or VLAN-ID etc.]
For other VM/Hypervisor-NVE protocol candidate, e.g. VDP, it can also be 
extended to support VM automatically join the VN.
The main point of this method is, using reserved VDP TLV Type to define 
some associate commands with auto join VN commands; or using a new filter 
information format to define this function, e.g. automatic join the VN, 
for the existing associate commands. 
When the EVB bridge, which also works as NVE, received the extended VDP 
commands it associates the VSI with a SBP, and further to create VN 
context for the VN which the VM wants to join, if the VN context does not 
exist; and further create an entry for the VM in the VRF, if this entry 
does not exists. The associate can be done by choosing one SBP from the 
SBP list which are configured by network administrator for automatic 
service provisioning purposes.
After that, the NVE using NVE-NVA protocol to synchronize with other NVEs 
in the same VN to realize the VN.
So we have two different mechanisms to realize the automatic VN 
provisioning. 
Based on above discussion, we suggest the working group accept the VN 
automatic service provision requirements.
Any comments or suggestions?
Thanks in advance!
Zhongyu

---

From: Joe Touch <[email-masked]>
Date: Wed, 25 Mar 2015 11:43:28 -0700

Hi,

I noticed this post, and wanted to give some general feedback.

First, I'm not sure I understand this as a standards-track document; it
seems more Informational at best.

Second, while the systems cited all focus on hypervisor and/or vxlan
configuration, we had a long project here at ISI that basically
accomplished most of the goals set out in this document at the IP layer.

It might be useful to take a look there; we had a discovery protocol
configuration managers, fault tolerance, etc. - and running code in
2000. That might provide an example of the kind of system you're trying
to indicate here.

The website is www.isi.edu/x-bone

Joe

On 3/20/2015 1:12 AM, [email-masked] wrote:
> Virtualization orchestration system etc., but, they agree the
> requirements are good for the VN service providing.
> 
> customer and/or shorten the time to market; 2), less manual
> configuration  and lower operation cost; 3), eliminate the possibility
> of manual configuration errors, and so on.
> 
> 2), Virtual Network accessed by enterprise network through secure
> Gateway (Section 3.1);
> 
> 3), Virtual Network accessed by enterprise network through VPN/PE
> (Section 3.2);
> 
> 5), Multiple Virtual Networks connected by other Virtual Network
> (Section 4.2);
> 
> 6), Multiple Virtual Networks accessed by enterprise network and
> Internet through secure Gateway (Section 4.3).
> 
> VN(s) and the Gateway(s). The basic VN consists of some VMs which
> connect to NVE and multiple NVE connect to each other by underlay
> network in one data center site. And the gateway may be any one or
> combination of NAT, firewall, secure gateway, load balancer, etc.
> 
> Gateway(s) can be automatically created(and automatically connected)
> then the VN can be automatic provided.
> 
> these devices, so we can define some interface to distribute the
> automatic creation command to these devices to realize the gateway
> automatic provision.
> 
> One method is, it can be done or supported by using the NVE-NVA
> protocol, because the gateway and the NVE can be resided in the same
> datacenter gateway generally. Please note that this may need more
> investigation and may be out of the NVO3 scope.
> 
> reasonable, we assume that VM is prepared by Hypervisor and is ready
> been configured with some basic parameters such as MAC address and/or IP
> address or VLAN-ID etc.]
> 
> some associate commands with auto join VN commands; or using a new
> filter information format to define this function, e.g. automatic join
> the VN, for the existing associate commands.
> 
> context for the VN which the VM wants to join, if the VN context does
> not exist; and further create an entry for the VM in the VRF, if this
> entry does not exists. The associate can be done by choosing one SBP
> from the SBP list which are configured by network administrator for
> automatic service provisioning purposes.
> 
> After that, the NVE using NVE-NVA protocol to synchronize with other
> NVEs in the same VN to realize the VN.
> 
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3
>

---

From: [email-masked]
Date: Thu, 26 Mar 2015 16:37:31 +0800

Hi Joe,

Thanks for your feedback and very helpful information. 

For first point, yes, it's for Informational, hope it accepted by WG as 
one requirement docu.

For second point, as you pointed out, the post is mainly focused on 
Hypervisor/Tenant system/VM
initiated automatic service provision. But there are other flavor of the 
automatic service provision
that not included in this post but in the draft, one of which is 
management initiated, -(NVA) accept the customer's 
request for VN, mapping the request to physical devices, and figure out 
and deliver the configuration commands to those devices,
and the devices executing the commands and realize the VN deployment.

The X-Bone can be used as an example to support the management initiated 
mechanism of VN automatic provision, 
although the usage environment is somehow different.

From the viewpoint of standardization, the management initiated mechanism 
may be difficult if not impractical.

This is why we try the post to discuss the practical mechanism.

Best regards,

Zhongyu

Joe Touch <[email-masked]> 
2015/03/26 02:43

收件人
[email-masked], "[email-masked]" <[email-masked]>, 
抄送

主题
Re: [nvo3] Automatic VN service provisioning discussion

Hi,

Joe