Subject: Re: [Supa] New Version Notification for draft-cheng-supa-ddc-use-cases-01.txt

From: Chongfeng <[email-masked]>
Date: Wed, 3 Dec 2014 09:26:32 +0800

I would like to see such a YANG model discussed here and eventually defined. It would let us focus on performing actions in the network without spending much time on complex details of the technology implementations.

In our case (China Telecom), our flow is  based on the level of  tenants' VPN, and bandwidth is also an important index of each flow. The bandwidth need to be optimized and guaranteed according to the requirement of tenant.  In order to do so, several informations are needed such as bandwidth with particular link and tenant requirement, VPN info, etc.

Chongfeng

From: Ying Cheng
Date: 2014-10-27 21:02
To: supa
CC: JFTremblay; Cathy Zhou; Georgios Karagiannis
Subject: Re: [Supa]New Version Notification for draft-cheng-supa-ddc-use-cases-01.txt
Hi all,

The updated DDC use case draft aligned with the latest charter has been posted to IETF repository via the following URL.

http://www.ietf.org/internet-drafts/draft-cheng-supa-ddc-use-cases-01.txt\

Please kindly review it. Any comments are welcomed.

Thanks and best regards,
Ying

2014-10-27 

Ying CHENG  程莹
China Unicom Network Technology Research Institute 中国联通网络技术研究院
Tel: +86-10-68799999-7702
Mobile: +86-18601102971

发件人： [email-masked] 
发送时间： 2014-10-27  20:14:00 
收件人： Cathy Zhou; Georgios Karagiannis; Ying Cheng(联通集团联通网络技术研究院); Ying Cheng(联通集团联通网络技术研究院); JF Tremblay; Cathy Zhou; JFTremblay; Georgios Karagiannis 
抄送： 
主题： New Version Notification for draft-cheng-supa-ddc-use-cases-01.txt 
A new version of I-D, draft-cheng-supa-ddc-use-cases-01.txt
has been successfully submitted by Cathy Zhou and posted to the
IETF repository.
Name: draft-cheng-supa-ddc-use-cases
Revision: 01
Title: Use Cases for Distributed Data Center Applications in SUPA
Document date: 2014-10-27
Group: Individual Submission
Pages: 9
URL:            http://www.ietf.org/internet-drafts/draft-cheng-supa-ddc-use-cases-01.txt
Status:         https://datatracker.ietf.org/doc/draft-cheng-supa-ddc-use-cases/
Htmlized:       http://tools.ietf.org/html/draft-cheng-supa-ddc-use-cases-01
Diff:           http://www.ietf.org/rfcdiff?url2=draft-cheng-supa-ddc-use-cases-01
Abstract:
   This document provides several distributed data center (ddc) use
   cases and explains how an operator could use SUPA (Shared Unified
   Policy Automation) to provide these applications.
                                                                                  
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
如果您错误接收了该邮件，请通过电子邮件立即通知我们。[email-masked]，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。 If you have received this email in error please notify us immediately by e-mail. Please reply to [email-masked] if you want to unsubscribe from this mail. We will immediately remove your information from our sending catalogue.

---

From: Andrew Qu <[email-masked]>
Date: Thu, 4 Dec 2014 07:56:49 +0000

Hi Chongfeng,

Are you looking for something like the following:

module ddc {
         namespace " ";
         //namespace need to be assigned by IANA
         prefix "ddc";
         import ietf-inet-types {
         prefix "inet";
         }
         organization "IETF ";
         contact " ";
         description "ddc yang module";
         revision " ";

         container vpnServices {
                  list vpnService {
                          key "vpnName";
                          leaf vpnName {
                                   description "VPN name.";
                                   type string;
                                   mandatory "true";
                          }
                          leaf vlanId {
                                   description "vlan id.";
                                   type uint16{
                                                             range "1 .. 4094";
                                                     }
                          }
                          leaf interfaceName {
                                   description "interface name.";
                                   type string;
                          }
                          leaf site {
                                   description "site information.";
                                   type string;
                          }
                          leaf vpnType {
                                   description "vpn instance type.";
                                   type enumeration {
             enum L2VPN;
             enum L3VPN;
        }
                          }
                          leaf bandWith {
                                   description "band width.";
                                   type uint32;
                          }
                          leaf latency {
                                   description "latency.";
                                   type uint32;
                          }
                  }
         }//container vpnServices

         container flowServices {
                  list flowService {
                          key "vpnName";
                          leaf vpnName {
                                   description "VPN name.";
                                   type string;
                                   mandatory "true";
                          }
                          leaf vpnType {
                                   description "vpn instance type.";
                                   type enumeration {
             enum L2VPN;
             enum L3VPN;
        }
                          }
                          leaf bandWith {
                                   description "band width.";
                                   type uint32;
                          }
                  }
         }

         container detourPolicys {
                  list detourPolicy {
                          key "vpnName";
                          leaf vpnName {
                                   description "VPN name.";
                                   type string;
                                   mandatory "true";
                          }
                          leaf flowName {
                                   description "flow name.";
                                   type string;
                          }
                          leaf protocol {
                                   description "protocol.";
                                   type uint8;
                          }
                          leaf srcIp {
                                   description "source ip.";
                                   type inet:ip-address;
                          }
                          leaf srcIpMask {
                                   description "source ip mask.";
                                   type uint8;
                          }
                          leaf destIp {
                                   description "destination ip.";
                                   type inet:ip-address;
                          }
                          leaf destIpMask {
                                   description "destination ip mask.";
                                   type uint8;
                          }
                          leaf srcPort {
                                   description "source port.";
                                   type uint16;
                          }
                          leaf destPort {
                                   description "destination port.";
                                   type uint16;
                          }
                  }
         }//container detourPolicys
}

Thanks,

Andrew

From: Supa [mailto:[email-masked]] On Behalf Of Chongfeng
Sent: Tuesday, December 02, 2014 5:27 PM
To: Ying Cheng; [email-masked]
Cc: JFTremblay; cathy.zhou; Georgios Karagiannis
Subject: Re: [Supa] New Version Notification for draft-cheng-supa-ddc-use-cases-01.txt

Chongfeng

From: Ying Cheng<mailto:[email-masked]>
Date: 2014-10-27 21:02
To: supa<mailto:[email-masked]>
CC: JFTremblay<mailto:[email-masked]>; Cathy Zhou<mailto:[email-masked]>; Georgios Karagiannis<mailto:[email-masked]>
Subject: Re: [Supa]New Version Notification for draft-cheng-supa-ddc-use-cases-01.txt
Hi all,

http://www.ietf.org/internet-drafts/draft-cheng-supa-ddc-use-cases-01.txt\<http://www.ietf.org/internet-drafts/draft-cheng-supa-ddc-use-cases-01.txt/>

Thanks and best regards,
Ying

2014-10-27
________________________________
Ying CHENG  程莹
________________________________
发件人： [email-masked]<mailto:[email-masked]>

如果您错误接收了该邮件，请通过电子邮件立即通知我们。[email-masked]，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。 If you have received this email in error please notify us immediately by e-mail. Please reply to [email-masked]<mailto:[email-masked]> if you want to unsubscribe from this mail. We will immediately remove your information from our sending catalogue.

---

From: Ying Cheng <[email-masked]>
Date: Thu, 4 Dec 2014 22:27:55 +0800

Hi Andrew,

Thanks a lot for your kindly drafting the initial model description as the starting point. After quick review, I have the following questions for our further consideration.

- What is the exact meaning of flowServices? Due to the limited property description, it is difficult to understand what the feature is. 
- I found that the detourPolicies was designed. Is it applicable for the use case specified in the latest DDC draft? What is the relationship between vpnServices and detourPolicies? Is there any overlap?

BR,
Ying

2014-12-04 

Ying CHENG  程莹

发件人： Andrew Qu 
发送时间： 2014-12-04  15:57:00 
收件人： Chongfeng; Ying Cheng(联通集团联通网络技术研究院); [email-masked] 
抄送： JFTremblay; cathy.zhou; Georgios Karagiannis 
主题： RE: [Supa] New Version Notification fordraft-cheng-supa-ddc-use-cases-01.txt 
 
Hi Chongfeng,

module ddc {
         namespace " ";
         
         container vpnServices {
                  list vpnService {
                          key "vpnName";
                          leaf vpnName {
                                   description "VPN name.";
                                   type string;
                                   mandatory "true";
                          }
                          leaf vlanId {
                                   description "vlan id.";                      
                                   type uint16{
                                                             range "1 .. 4094";
                                                     }
                          }
                          leaf interfaceName {
 
         container flowServices {
                  list flowService {
                          key "vpnName";
                          leaf vpnName {
                                   description "VPN name.";
                                   type string;
                                   mandatory "true";
                          }
                          leaf vpnType {

Thanks,
 
Andrew

 

Chongfeng
 
From: Ying Cheng
Date: 2014-10-27 21:02
To: supa

 
 
Thanks and best regards,
Ying

 
2014-10-27 

Ying CHENG  程莹

如果您错误接收了该邮件，请通过电子邮件立即通知我们。[email-masked]，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。
If you have received this email in error please notify us immediately by e-mail. Please reply to [email-masked] if you want to unsubscribe from this mail. We will immediately remove your information from our sending catalogue.

---

From: Chongfeng <[email-masked]>
Date: Fri, 5 Dec 2014 16:33:26 +0800

Thank you Andrew for sharing this. It’s a good start point which makes it easier for us to continue the discussion and deliver concrete work. I will read more carefully and give my feedback soon. 

One quick question for the group: I see almost all parts of this YANG model are VPN related. Are we assuming that we only focus on VPN based DDC here by default?

发件人： Andrew Qu 

module ddc {
         namespace " ";
         
         container vpnServices {
                  list vpnService {
                          key "vpnName";
                          leaf vpnName {
                                   description "VPN name.";
                                   type string;
                                   mandatory "true";
                          }
                          leaf vlanId {
                                   description "vlan id.";                      
                                   type uint16{
                                                             range "1 .. 4094";
                                                     }
                          }
                          leaf interfaceName {
 
         container flowServices {
                  list flowService {
                          key "vpnName";
                          leaf vpnName {
                                   description "VPN name.";
                                   type string;
                                   mandatory "true";
                          }
                          leaf vpnType {

Thanks,
 
Andrew

 

Chongfeng
 
From: Ying Cheng
Date: 2014-10-27 21:02
To: supa

 
 
Thanks and best regards,
Ying

 
2014-10-27 

Ying CHENG  程莹

---

From: Tina TSOU <[email-masked]>
Date: Tue, 9 Dec 2014 12:30:45 +0000

Dear Chongfeng et al,

IMHO, the IP based DDC should also be included, at least Google and China Telecom have such cases.

So there should be vpnType in the DDC service yang model.

module: ddc
   +--rw vpnServices
   |  +--rw vpnService* [vpnName]
   |     +--rw vpnName          string
   |     +--rw vlanId?          uint16
   |     +--rw interfaceName?   string
   |     +--rw site?            string
   |     +--rw vpnType?         enumeration
   |     +--rw bandWith?        uint32
   |     +--rw latency?         uint32
   +--rw flowServices
   |  +--rw flowService* [vpnName]
   |     +--rw vpnName     string
   |     +--rw vpnType?    enumeration
   |     +--rw bandWith?   uint32
   +--rw detourPolicys
      +--rw detourPolicy* [vpnName]
         +--rw vpnName       string
         +--rw flowName?     string
         +--rw protocol?     uint8
         +--rw srcIp?        inet:ip-address
         +--rw srcIpMask?    uint8
         +--rw destIp?       inet:ip-address
         +--rw destIpMask?   uint8
         +--rw srcPort?      uint16
         +--rw destPort?     uint16

Thank you,
Tina

On Dec 5, 2014, at 4:34 PM, Chongfeng <[email-masked]<mailto:[email-masked]>> wrote:

收件人： Chongfeng; Ying Cheng(联通集团联通网络技术研究院); [email-masked]<mailto:[email-masked]>

module ddc {
         namespace " ";

         container vpnServices {
                  list vpnService {
                          key "vpnName";
                          leaf vpnName {
                                   description "VPN name.";
                                   type string;
                                   mandatory "true";
                          }
                          leaf vlanId {
                                   description "vlan id.";
                                   type uint16{
                                                             range "1 .. 4094";
                                                     }
                          }
                          leaf interfaceName {

         container flowServices {
                  list flowService {
                          key "vpnName";
                          leaf vpnName {
                                   description "VPN name.";
                                   type string;
                                   mandatory "true";
                          }
                          leaf vpnType {

Thanks,

Andrew

To: Ying Cheng; [email-masked]<mailto:[email-masked]>

Chongfeng

Thanks and best regards,
Ying

2014-10-27

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<http://tools.ietf.org>.
The IETF Secretariat

如果您错误接收了该邮件，请通过电子邮件立即通知我们。[email-masked]<mailto:[email-masked]>，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。 If you have received this email in error please notify us immediately by e-mail. Please reply to [email-masked]<mailto:[email-masked]> if you want to unsubscribe from this mail. We will immediately remove your information from our sending catalogue.

如果您错误接收了该邮件，请通过电子邮件立即通知我们。[email-masked]<mailto:[email-masked]>，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。 If you have received this email in error please notify us immediately by e-mail. Please reply to [email-masked]<mailto:[email-masked]> if you want to unsubscribe from this mail. We will immediately remove your information from our sending catalogue.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 11 Dec 2014 09:04:23 +0100

Hi,

can someone explain what is DDC specific here?

/js

> _______________________________________________
> Supa mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/supa

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Ying Cheng <[email-masked]>
Date: Thu, 11 Dec 2014 21:03:58 +0800

Hi Juergen,

DDC means geographically distributed data centers here. The next version of this draft aims to propose DDC service YANG model which can reflect the scenarios described in the current draft.

BR,
Ying

2014-12-11 

Ying CHENG  程莹

发件人： Juergen Schoenwaelder 
发送时间： 2014-12-11  16:04:59 
收件人： Tina TSOU 
抄送： [email-masked]; [email-masked]; Chongfeng 
主题： Re: [Supa] New Version Notificationfordraft-cheng-supa-ddc-use-cases-01.txt 
Hi,
can someone explain what is DDC specific here?
/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 11 Dec 2014 15:10:50 +0100

OK. But my question remains unanswered. My question was:

    What in the outlined YANG tree is DDC specific?

Note that it might be a feature if at the end nothing really needs to
be DDC specific. Anway, I am fine with finding answers in updated
I-Ds if that is the way to go.

/js

---

From: Ying Cheng <[email-masked]>
Date: Fri, 12 Dec 2014 17:33:54 +0800

Hi Juergen,

We’ve discussed this issue offline and proposed the ddc model description for the scenario which may help the group to better understand it. 
A tenant's network service is deployed across multiple data centers. It is needed for the network to create VPN among data centers. The target model should provide controller with the vpn sites, interfaces, vpn type, vpn bandwidth, vpn latency, tenant vlan, etc..  Branch "+--rw createVpnServices" is designed for this.
When the VPN bandwidth utilization exceeds or falls below certain thresholds, there will be traffic optimization for the VPN. The target model should provide controller with the bandwidth adjustment of VPN. Branch "+--rw optimizeTrafficServices" is designed for this. 
In the scenarios of fixed VPN bandwidth among datacenters, the bandwidth of VPN can't be adjusted. For example, a tenant builds its own data centers in different cities and leases the carrier network for connecting the data centers. The traffic is not balanced in different VPN links. The tenant need to adjust partial traffic from its default path to specified path (such as specifying a flow pass specified nodes).  Branch "+--rw specifyFlowPaths" is designed for this.
 
Below is just an example. YANG experts, please feel free to make modifications and comments.
 
module: ddc
   +--rw createVpnServices
   |  +--rw vpnService* [vpnName]
   |     +--rw vpnName                  string
   |     +--rw vlanId?                  uint16
   |     +--rw dataCenterInformation* [site]
   |     |  +--rw interfaceName?   string
   |     |  +--rw site             string
   |     +--rw vpnType?                 enumeration
   |     +--rw bandWidth?                uint32
   |     +--rw latency?                 uint32
   +--rw optimizeTrafficServices
   |  +--rw optimizeTrafficService* [vpnName]
   |     +--rw vpnName     string
   |     +--rw vpnType?    enumeration
   |     +--rw bandWidth?   uint32
   +--rw specifyFlowPaths
   |  +--rw specifyFlowPath* [vpnName]
   |     +--rw vpnName        string
   |     +--rw vpnType?       enumeration
   |     +--rw flowName?      string
   |     +--rw node-search*   string
   +--rw detourPolicys
      +--rw detourPolicy* [vpnName]
         +--rw vpnName       string
         +--rw flowName?     string
         +--rw protocol?     uint8
         +--rw srcIp?        inet:ip-address
         +--rw srcIpMask?    uint8
         +--rw destIp?       inet:ip-address
         +--rw destIpMask?   uint8
         +--rw srcPort?      uint16
         +--rw destPort?     uint16

BR, 
Ying

2014-12-12 

Ying CHENG  程莹

发件人： Juergen Schoenwaelder 
发送时间： 2014-12-11  22:11:05 
收件人： Ying Cheng(联通集团联通网络技术研究院) 
抄送： Tina TSOU; [email-masked]; [email-masked]; Chongfeng 
主题： Re: [Supa] New VersionNotificationfordraft-cheng-supa-ddc-use-cases-01.txt

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 12 Dec 2014 10:56:28 +0100

> In the scenarios of fixed VPN bandwidth among datacenters, the bandwidth of VPN can't be adjusted. For example, a tenant builds its own data centers in different cities and leases the carrier netwo…

I think it is important to distinguish use case description and a data
model proposal. It seems to me data centers want to manage VPNs but I
think the requirement to manage VPNs may be not just data center
specific. Hence my question.

> Below is just an example. YANG experts, please feel free to make modifications and comments.

Well, to be clear, there is no YANG here - just a tree diagram.

I wonder whether you really mean IP masks or IP prefixes (you should
not think IPv4 specific) but then I do not know what the semantics of
these leafs are either. Someone needs to write the YANG for this to
be something one can comment on. And yes, I question whether the module
should be called ddc (despite the fact that this does not follow the
naming guidelines / requirements anyway).

/js

---

From: Ying Cheng <[email-masked]>
Date: Mon, 15 Dec 2014 17:46:04 +0800

Hi Juergen,

IMHO, There are 3 levels:

1. General YANG model
2. DDC-specific YANG model
3. Operator-specific DDC service YANG model 

Which ones do you think we should do here?

Attached please kindly reivew the YANG model of the tree I send in my last email.

Thanks and best regards,
Ying

2014-12-15 

Ying CHENG  程莹

发件人： Juergen Schoenwaelder 
发送时间： 2014-12-12  17:56:40 
收件人： Ying Cheng(联通集团联通网络技术研究院) 
抄送： [email-masked]; Chongfeng; [email-masked]; Tina TSOU 
主题： Re: [Supa] NewVersionNotificationfordraft-cheng-supa-ddc-use-cases-01.txt

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 15 Dec 2014 18:08:45 +0100

> Attached please kindly reivew the YANG model of the tree I send in my last email.

The descriptions are almost empty and hence I can't review this since
it is unclear what all the objects are supposed to do. Anyway, do you
think your model is of type 1., 2., or 3.?

/js

---

From: Ying Cheng <[email-masked]>
Date: Wed, 17 Dec 2014 16:45:20 +0800

Hi Juergen,

Ddc model is used in the interface between management system/application and controller (called northbound interface). It is for the traffic optimization between data centers.

When a tenant's network service is deployed in multiple data centers (e.g. DCs in different cities), VPN (with latency and bandwidth requirements) is required between data centers. The management system/application may require the controller to create VPN between data centers for the tenant. When the tenant traffic is below or over certain threshold, the management system/application may require the controller to adjust the bandwidth of the VPN. When the tenant's service is deployed in 3 or more data centers, the bandwidth utilization of each link may be imbalance. The management system/application may adjust some flow to pass certain nodes (or links), so as to improve the bandwidth utilization (or reduce cost). 

In the southbound of controller, the controller will use the southbound models (e.g. "draft-ietf-netmod-routing-cfg", draft-zhuang-l3vpn-yang-cfg, etc.) to configure the network elements.

The ddc YANG model is proposed with description as below. Please kindly review it.

--------------------------------------------------------------------------------------
module ddc {
   namespace "***";
   //namespace need to be assigned by IANA
   prefix "ddc";
   import ietf-inet-types {
   prefix "inet";
   }
   organization "IETF";
   contact "";
   description "ddc yang module";
   revision "";
   
   container createVpnServices {
               //management system/ application requires controller to create vpn for a tenant between data centers. vpn name, tennant vlan id, vpn sites and interfaces, vpn type, bandwidth requirement and latency requirement should be told to controller
       list vpnService {
           key "vpnName";
           leaf vpnName {
               description "VPN name.";
               type string;
               mandatory "true";
           }
           leaf vlanId {
               description "vlan id.";            
               type uint16{
                           range "1 .. 4094";
                       }
           }
                 //this is the vlan id of the tenant
           list dataCenterInformation {
               key "site";
               leaf interfaceName {
                   description "interface name for data center.";
                   type string;
               }

               leaf site {
                   description "site information for data center.";
                   type string;
               }
           }
                 //these are the sites and the interfaces that the vpn connects to
           leaf vpnType {
               description "vpn instance type.";
               type enumeration {
                   enum L2VPN;
                   enum L3VPN;
               }
           }
                 //this is the type of vpn. it can be L2VPN or L3VPN
           leaf bandWith {
               description "band width.";            
               type uint32;
           }
                 //this is the bandwidth requirement of vpn
           leaf latency {
               description "latency.";            
               type uint32;
           }
                 //this is the latency requirement of vpn
       }
   }//container createVpnServices

   container optimizeTrafficServices {
             //management system/ application requires controller to adjust the bandwidth of VPN to optimize the traffic when the bandwidth utilization is below or over certain threshold. vpn name, vpn type and adjusted bandwidth should be told to controller.
       list optimizeTrafficService {
           key "vpnName";
           leaf vpnName {
               description "VPN name.";
               type string;
               mandatory "true";
           }
                 //this is the name of vpn that needs to be adjusted.
           leaf vpnType {
               description "vpn instance type.";
               type enumeration {
                   enum L2VPN;
                   enum L3VPN;
               }
           }
                 //this is the type of vpn that needs to be adjusted.
           leaf bandWith {
               description "band width.";            
               type uint32;
           }
                 //this is the adjusted bandwidth of the vpn.
       }
   }//container optimizeTrafficServices

   container specifyFlowPaths {
               //to improve the bandwidth utilization (or reduce the cost, or other reason), management system/ application requires controller to adjust certain flows to pass certain nodes (or links). vpn name, vpn type, adjusted flow and specified nodes (that the flow should pass) should be told to controller. so that the controller can configure the network elements to change the VRF table and routing table.
       list specifyFlowPath {
           key "vpnName";
           leaf vpnName {
               description "VPN name.";
               type string;
               mandatory "true";
           }
                 //this is the name of vpn that the adjusted flow belong to.
           leaf vpnType {
               description "vpn instance type.";
               type enumeration {
                   enum L2VPN;
                   enum L3VPN;
               }
           }
                 //this is the type of vpn that the adjusted flow belong to.
           leaf flowName {
               description "flow name.";
               type string;
           }
                 //this is the adjusted flow.
           leaf-list node-search {
               type string;
               description "List of node names to search";
           }
                 //this is nodes list that the adjusted flow will pass.
       }
   }//container specifyFlowPaths

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

BR,
Ying

2014-12-17 

Ying CHENG  程莹

发件人： Juergen Schoenwaelder 
发送时间： 2014-12-16  01:08:51 
收件人： Ying Cheng(联通集团联通网络技术研究院) 
抄送： [email-masked]; Tina TSOU; [email-masked]; Chongfeng 
主题： Re: [Supa]NewVersionNotificationfordraft-cheng-supa-ddc-use-cases-01.txt

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 18 Dec 2014 09:14:16 +0100

Hi,

I did not ask for another explanation of the use case. We are
obviously disconnected. Let me try an analogy. Lets consider a
screwdriver. It is a tool, a pretty generic tool. I can use it to
repair my bike, to mount a lamp, or to fix something on the wall.  I
have one screwdriver, I do not have a bike-fixing-screwdriver, a
lamp-mount-screwdriver, a fix-something-on-the-wall-screwdriver.

Perhaps all you need is a generic VPN management data model and then
you can use it to solve your DDC problem, others can use it to solve
other problems. Does this help to understand my question?

/js

PS: Descriptions go into description statements and not into comments.
    And they need to be more detailed, especially for opaque 'string'
    objects.

---

From: Tina TSOU <[email-masked]>
Date: Thu, 18 Dec 2014 11:53:53 +0000

Dear Juergen,

A generic VPN management data model could be all we need. It can be used to solve China Unicom's and others' DDC problem. Others can use it to solve other problem.
This is one way forward.

The other way is to think about DDC problems, like the following, and have a DDC data model. (DCI and DC egress, not including inside of DC.)
1. Physical and virtual data center scenarios. Diego and Luis from Telefonica, Jun and Fuliang from Cernet may have something to add here.
2. At the physical data center gateway, convert the internal VNI into external VPN ID.
3. RR+ load balance at data center multi egresses, to differentiate users and services. Chongfeng from China Telecom may have something to add here.
4. Separte flows between public network and priviate network services, separate public cloud and private cloud.
5. Data Center Interconnection, L2/L3 VPN, or IP based. Ying from China Teleocm, Junda from Google, King from Tencent may have something to add here.
6. Cloud broker at DDC

Either way is fine for me.

Dear Benoit, 

Which way above do you wish us to move into?

Thank you,
Tina

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Thursday, December 18, 2014 4:14 PM
To: Ying Cheng
Cc: [email-masked]; Chongfeng; [email-masked]; Tina TSOU
Subject: Re: [Supa] NewVersionNotificationfordraft-cheng-supa-ddc-use-cases-01.txt

Hi,

I did not ask for another explanation of the use case. We are obviously disconnected. Let me try an analogy. Lets consider a screwdriver. It is a tool, a pretty generic tool. I can use it to repair my bike, to mount a lamp, or to fix something on the wall.  I have one screwdriver, I do not have a bike-fixing-screwdriver, a lamp-mount-screwdriver, a fix-something-on-the-wall-screwdriver.

Perhaps all you need is a generic VPN management data model and then you can use it to solve your DDC problem, others can use it to solve other problems. Does this help to understand my question?

/js

On Wed, Dec 17, 2014 at 04:45:20PM +0800, Ying Cheng wrote:
> 主题： Re: 
> [Supa]NewVersionNotificationfordraft-cheng-supa-ddc-use-cases-01.txt
>

---

From: Tina TSOU <[email-masked]>
Date: Thu, 18 Dec 2014 12:01:03 +0000

Dear all,

Oops, correct King's email address [email-masked].

Thank you,
Tina

> On Dec 18, 2014, at 7:53 PM, Tina TSOU <[email-masked]> wrote:
> 
> Dear Juergen,
>

---

From: "Jun Bi" <[email-masked]>
Date: Thu, 18 Dec 2014 21:20:38 +0800

Hi All,

I think Tina's email is a very good summary on the problem in DDC.

Especially,

How to dynamically and flexibly configure the virtual data center functions
over physical data center.
Separating flows between public network and private network services is a
very nice feature to network service and management.
The process of elephant flows and mice flows in DDC could be different,
depending the requirement for delay and throughput..

I think those problems /new features could be handled by SUPA.

Jun Bi
Tsinghua Univ./CERNET

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tina
TSOU
Sent: Thursday, December 18, 2014 8:01 PM
To: Juergen Schoenwaelder; Ying Cheng; Benoit Claise
Cc: [email-masked]; [email-masked]; [email-masked]; Chongfeng
Subject: Re: [Supa]
NewVersionNotificationfordraft-cheng-supa-ddc-use-cases-01.txt

Dear all,

Thank you,
Tina

> A generic VPN management data model could be all we need. It can be used
to solve China Unicom's and others' DDC problem. Others can use it to solve
other problem.
> This is one way forward.
> 
> The other way is to think about DDC problems, like the following, and 
> have a DDC data model. (DCI and DC egress, not including inside of DC.) 1.
Physical and virtual data center scenarios. Diego and Luis from Telefonica,
Jun and Fuliang from Cernet may have something to add here.
> 3. RR+ load balance at data center multi egresses, to differentiate users
and services. Chongfeng from China Telecom may have something to add here.
> 5. Data Center Interconnection, L2/L3 VPN, or IP based. Ying from China
Teleocm, Junda from Google, King from Tencent may have something to add
here.
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]]
> Subject: Re: [Supa] 
> NewVersionNotificationfordraft-cheng-supa-ddc-use-cases-01.txt
> 
> Hi,
> 
> I did not ask for another explanation of the use case. We are obviously
disconnected. Let me try an analogy. Lets consider a screwdriver. It is a
tool, a pretty generic tool. I can use it to repair my bike, to mount a
lamp, or to fix something on the wall.  I have one screwdriver, I do not
have a bike-fixing-screwdriver, a lamp-mount-screwdriver, a
fix-something-on-the-wall-screwdriver.
> 
> Perhaps all you need is a generic VPN management data model and then you
can use it to solve your DDC problem, others can use it to solve other
problems. Does this help to understand my question?
>> Ddc model is used in the interface between management system/application
and controller (called northbound interface). It is for the traffic
optimization between data centers.
>> 
>> When a tenant's network service is deployed in multiple data centers
(e.g. DCs in different cities), VPN (with latency and bandwidth
requirements) is required between data centers. The management
system/application may require the controller to create VPN between data
centers for the tenant. When the tenant traffic is below or over certain
threshold, the management system/application may require the controller to
adjust the bandwidth of the VPN. When the tenant's service is deployed in 3
or more data centers, the bandwidth utilization of each link may be
imbalance. The management system/application may adjust some flow to pass
certain nodes (or links), so as to improve the bandwidth utilization (or
reduce cost). 
>> 
>> In the southbound of controller, the controller will use the southbound
models (e.g. "draft-ietf-netmod-routing-cfg", draft-zhuang-l3vpn-yang-cfg,
etc.) to configure the network elements.
>> -
>> ----------------
>>               //management system/ application requires controller to
create vpn for a tenant between data centers. vpn name, tennant vlan id, vpn
sites and interfaces, vpn type, bandwidth requirement and latency
requirement should be told to controller
>>             //management system/ application requires controller to
adjust the bandwidth of VPN to optimize the traffic when the bandwidth
utilization is below or over certain threshold. vpn name, vpn type and
adjusted bandwidth should be told to controller.
>>               //to improve the bandwidth utilization (or reduce the cost,
or other reason), management system/ application requires controller to
adjust certain flows to pass certain nodes (or links). vpn name, vpn type,
adjusted flow and specified nodes (that the flow should pass) should be told
to controller. so that the controller can configure the network elements to
change the VRF table and routing table.

---

From: Ying Cheng <[email-masked]>
Date: Thu, 25 Dec 2014 15:08:43 +0800

Hi Juergen, Tina, et al,

I agree with Tina's problem grouping proposal and understand Juergen's concern. 

The current YANG model draft comes from the DDC interconnection scenario in the real world. If we aim to develop the generic VPN mgmt data model, it is needed for us to provide the panorama of VPN, in which DDC use case is not enough. I put forward to narrow our target at this stage, as Tina's second development proposal, and focus on the DDC interconnection data model. In this case, if we can come to intermediated achievement, we can also consider the generic model as the further study. 

Attached please kindly review the updated ddc YANG model. Looking forward to your comments. 

Merry Xmas!
Ying

2014-12-25 

Ying CHENG  程莹

发件人： Tina TSOU 
发送时间： 2014-12-18  19:54:01 
收件人： Juergen Schoenwaelder; Ying Cheng(联通集团联通网络技术研究院); Benoit Claise 
抄送： [email-masked]; Chongfeng; [email-masked]; [email-masked] 
主题： RE: [Supa]NewVersionNotificationfordraft-cheng-supa-ddc-use-cases-01.txt 
 
Dear Juergen,
-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]]
Sent: Thursday, December 18, 2014 4:14 PM
To: Ying Cheng
Cc: [email-masked]; Chongfeng; [email-masked]; Tina TSOU
Subject: Re: [Supa] NewVersionNotificationfordraft-cheng-supa-ddc-use-cases-01.txt
Hi,

---

From: "Scott O. Bradner" <[email-masked]>
Date: Thu, 25 Dec 2014 07:21:46 -0500

I’ve been watching from the sidelines but (poked by Tina) for what it is worth here is Harvard’s use case & a suggestion
for scope

Harvard has a LOT of VPNs 

until recently they were essentially all within the university and used to restrict access to data center resources
of these, most are connect on demand from individual user machines - not sometime that may be worth modeling
since they are so dynamic

a few of these are connecting school-level data centers to the main campus data center - not many but worth modeling

in the last year we have had a major shift.  The University is engaged in a major push to the cloud - during the push (i.e. before the move is well along) there are a lot of applications in the cloud that need to securely access services in the data center - services that we do not expose to the general Internet.  VPNs have been the mechanism of choice 
to secure these connections - the number is growing far faster than we find operationally supportable -largely because there are may independent development groups moving their own applications to the cloud -  this is something that would be great to be able to model and monitor

In the longer run, many of the services themselves will be moved to the cloud, at which time the need
for such a proliferation pf VPNs but I expect there still will be quite a few that persist “forever”

my suggestion for the scope is: 
"VPN services data model including within an organization and between organizations”.

Scott

> On Dec 25, 2014, at 2:08 AM, Ying Cheng <[email-masked]> wrote:
> 
> Hi Juergen, Tina, et al,
>  
> <ddc v1.2 yang.txt>_______________________________________________
> Supa mailing list
> [email-masked]

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Thu, 25 Dec 2014 18:47:11 +0000

Hi Juergen,

I'd say the DDC cases we have in mind need to go beyond generic VPN management, as we are considering the management of overlays across the different physical DCs. I guess we'd need a generic overlay data model, including VPN management.

Be goode and may the New Year be extremely goode to you all,

--
PLEASE NOTE MY NEW EMAIL ADDRESS
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: Tina TSOU <[email-masked]>
Date: Fri, 26 Dec 2014 03:45:19 +0000

Dear Diego,

You meant for example VM migration across domains?

Try to stitch your proposed scope and Scott's proposed scope, how about
"Generic overlay including VPN services data model, within an organization and between organizations"?

Happy Holidays!

Thank you,
Tina

-----Original Message-----
From: DIEGO LOPEZ GARCIA [mailto:[email-masked]] 
Sent: Friday, December 26, 2014 2:47 AM
To: Juergen Schoenwaelder
Cc: Ying Cheng; [email-masked]; Tina TSOU; [email-masked]; Chongfeng
Subject: Re: [Supa] NewVersionNotificationfordraft-cheng-supa-ddc-use-cases-01.txt

Hi Juergen,

On 18 Dec 2014, at 09:14 , Juergen Schoenwaelder <[email-masked]> wrote:

>> -----------------

Dr Diego R. Lopez
Telefonica I+D

---

From: Tina TSOU <[email-masked]>
Date: Mon, 29 Dec 2014 10:18:45 +0000

Dear Scott,

Thank you for the real and concrete use cases, and scope it clearly. Taking Diego's another email into account, would you be OK with something like "Generic overlay including VPN services data model, within an organization and between organizations"?

Regarding Harvard cases, how do clients use it? For example, do we have more detailed examples of VM replication or VM failures that would use this?

Thank you,
Tina

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Scott O. Bradner
Sent: Thursday, December 25, 2014 8:22 PM
To: Ying Cheng
Cc: [email-masked]; Tina TSOU; Chongfeng; Juergen Schoenwaelder; [email-masked]; Benoit Claise; [email-masked]
Subject: Re: [Supa] NewVersionNotificationfordraft-cheng-supa-ddc-use-cases-01.txt

I’ve been watching from the sidelines but (poked by Tina) for what it is worth here is Harvard’s use case & a suggestion for scope

until recently they were essentially all within the university and used to restrict access to data center resources of these, most are connect on demand from individual user machines - not sometime that may be worth modeling since they are so dynamic

in the last year we have had a major shift.  The University is engaged in a major push to the cloud - during the push (i.e. before the move is well along) there are a lot of applications in the cloud that need to securely access services in the data center - services that we do not expose to the general Internet.  VPNs have been the mechanism of choice to secure these connections - the number is growing far faster than we find operationally supportable -largely because there are may independent development groups moving their own applications to the cloud -  this is something that would be great to be able to model and monitor

In the longer run, many of the services themselves will be moved to the cloud, at which time the need for such a proliferation pf VPNs but I expect there still will be quite a few that persist “forever”

Scott

> 主题： RE: 
> have a DDC data model. (DCI and DC egress, not including inside of DC.) 1. Physical and virtual data center scenarios. Diego and Luis from Telefonica, Jun and Fuliang from Cernet may have something to add here.
> > --------------------------------------------------------------------
> > --
> > ----------------
> > module ddc {
> >    namespace "***";
> > The descriptions are almost empty and hence I can't review this 
> > since it is unclear what all the objects are supposed to do. Anyway, 
> > do you think your model is of type 1., 2., or 3.?
> > /js
> > --