Subject: [Supa] About the scope of SUPA

From: Chongfeng <[email-masked]>
Date: Mon, 12 Jan 2015 10:28:08 +0800

Hi all,

This thread is discussing more about the scope of SUPA so I changed the title. I've been watching this thread and it seems to me that now we're closer to a clear solid scope than ever. However, I just want to make sure that my case is in the scope. 

China Telecom is testing and implementing the DRE(DC  Router  Enhancement) schema now.  In our case, an management system monitors traffic volume on the link conveying the exporting traffic of a DC. When the volume exceeds the threshold set by the system, the system designs traffic adjustment model to move some flows from that link to another exporting link in order to make sure that the traffic volume on link below the threshold. 

Hope that the management and configuration model for the case above can be covered by SUPA.

Chongfeng Xie

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Georgios Karagiannis
Sent: Wednesday, January 07, 2015 12:57 AM
To: Scott O. Bradner; Ying Cheng
Cc: [email-masked]; DIEGO LOPEZ GARCIA; Tina TSOU; Chongfeng; Juergen Schoenwaelder; [email-masked]
Subject: Re: [Supa] NewVersionNotificationfordraft-cheng-supa-ddc-use-cases-01.txt

Dear Scott, Dear Ying, Dear all,

I am pleased to see that we are currently converging to something that is acceptable by the SUPA team.
The below mentioned issue is in my opinion related to how large will the scope of SUPA be.
From what I can recall from previous discussions we need to narrow down the scope of SUPA as much as possible, while at the same time the provided protocol work solution should be generic, flexible and extensible enough.

Using the proposal of Tina, will it be acceptable to define the scope of SUPA as follows?:

"SUPA focuses on a generic L3VPN data model, that can be applied within an organization and between trusted organizations"

Best regards,
Georgios

> -----Original Message-----
> From: Supa [mailto:[email-masked]] On Behalf Of Scott O. 
> Bradner
> Sent: Tuesday, January 06, 2015 2:11 AM
> To: Ying Cheng
> Cc: [email-masked]; DIEGO LOPEZ GARCIA; Chongfeng; Tina TSOU; 
> Juergen Schoenwaelder; [email-masked]
> Subject: Re: [Supa] 
> NewVersionNotificationfordraft-cheng-supa-ddc-use-cases-
> 01.txt
> 
> I think there is a big issue there - within an organization you are in 
> a single trust zone between organizations you are in multiple trust 
> zones - I am not sure what that changes but I am quite sure it changes 
> quite a bit
> 
> Scott
> 
> > On Jan 5, 2015, at 8:03 PM, Ying Cheng <[email-masked]> wrote:
> >
> > Hi Tina, Scott, et al,
> >
> > Thanks for your summary on our further work. Personally, it is 
> > approching
> the final target. There is only one minor question from my side: is it 
> necessary to mention "within an organization and between 
> organizations" in the scope, which covers all the VPN?
> >
> > Happy new year!
> > Ying
> >
> >
> > 2015-01-06
> > Ying CHENG  程莹
> > China Unicom Network Technology Research Institute 中国联通网络技术研究院
> > Tel: +86-10-68799999-7702
> > Mobile: +86-18601102971
> >
> > 发件人： Tina TSOU
> > 发送时间： 2014-12-26  11:45:43
> > 收件人： DIEGO LOPEZ GARCIA; Juergen Schoenwaelder; [email-masked]
> > 抄送： Ying Cheng(联通集团联通网络技术研究院); [email-masked]; [email-masked]; 
> > Chongfeng
> > 主题： Re:
> > [Supa]NewVersionNotificationfordraft-cheng-supa-ddc-use-cases-01.txt
> > 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,
> > 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, On 18 
> > Dec 2014, at 09:14 , Juergen Schoenwaelder 
> > <[email-masked]>
> wrote:
> > > 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.
> > >
> > > On Wed, Dec 17, 2014 at 04:45:20PM +0800, Ying Cheng wrote:
> > >> 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
> > >>
> > >>   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
> > >> }
> > >>
> > >> -----------------------------------------------------------------
> > >> --
> > >> --
> > >>
> > >> BR,
> > >> Ying
> > >>
> > >> 2014-12-17
> > >>
> > >>
> > >>
> > >> Ying CHENG  程莹
> > >> China Unicom Network Technology Research Institute 中国联通网络技术研究院
> > >> Tel: +86-10-68799999-7702
> > >> Mobile: +86-18601102971
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> 发件人： 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.
> > >> tx
> > >> t
> > >>
> > >> On Mon, Dec 15, 2014 at 05:46:04PM +0800, Ying Cheng wrote:
> > >>> 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.
> > >>>
> > >> 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
> > >> --
> > >> 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/>
> > >
> > >> _______________________________________________
> > >> 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/>
> > >
> > > _______________________________________________
> > > Supa mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/supa
> > --
> > 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 
> > _______________________________________________
> > Supa mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/supa
> > _______________________________________________
> > Supa mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/supa
> 
> _______________________________________________
> Supa mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/supa
_______________________________________________
Supa mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/supa

---

From: Georgios Karagiannis <[email-masked]>
Date: Mon, 12 Jan 2015 09:57:00 +0000

Hi Chongfeng Xie,
Thank you very much for your email.
Please note that the scope of SUPA is the one that is described in the SUPA charter description sent by Tina last Friday, see below.
Regarding, your question, in my opinion what you described is in the scope of SUPA.

> From: Supa [mailto:[email-masked]] On Behalf Of Tina TSOU

> Sent: Friday, January 09, 2015 4:33 PM

> To: [email-masked]

> Subject: [Supa] Charter discussion

> Dear all,

> Here is the current charter for discussion, great thanks to Diego, John,

> Juergen, Marie-Jose, Scott et al.

> Description of Working Group:

> Version: 00

> Date: UTC 2015.01.09

> The rapid increase in the amount and type of traffic and the increasing

> complexity of network architectures make it significantly more challenging for

> operations and management applications (OAMA) to manage networks and to deploy

> new services. Programmatic ways to configure and operate these networks, which

> are often called software-defined networks, are one means that could be used

> by network operators to provide significant benefits in design and deployment

> agility.

> The purpose of the SUPA (Shared Unified Policy Automation) working group is to

> develop a set of generic YANG-based data models to enable management and

> automation of network services within an administrative domain. The service

> data models will be derived from a single information model, ensuring that

> they can be shared and reusedas managed objects. Similarly, a policy model

> will then be derived from the same information model to help manage and

> automate the generation and deployment of services. Policy rules will be used

> to define the operational aspects of both the "southbound" (e.g., controller

> to device) and "northbound" (e.g., controller to application) portions of the

> service environment. The first example that the working group will focus on

> will be VPN management.

> This WG introduces the concepts of multi-level and multi-technology network

> abstractions to address the current separation between development and

> deployment operations. Business agility, along with OpEx reduction, cannot be

> obtained unless it becomes possible to deploy changes as products. Policy-

> based management is one way to help do this, but we need better abstractions

> of network resources and services to achieve these goals. The WG plans to

> create three types of YANG models: (1) a general network topology model, (2) a

> model of network service configuration, and (3) a model for representing

> policy rules. The combination of these three models will enable OAMA to

> request information that they need, such as topology information, as well as

> to define policy rules to configure network services. As a result,

> standardized models between OAMA and network controllers of all types can be

> established while supporting automatic and programmable configuration. This

> may beneficially i!

> mprove th

>  e experience of operators in configuration and management of network services

> by allowing OAMA to request these network services from single or multiple

> network controllers. The combination of standardized policy and data models

> will enable network services to be quickly and dynamically created, deleted,

> and modified.

> Work items for this WG include:

> 1) A set of Yang models focused on VPN management within a single

> administrative domain, but which will later be expanded to accommodate

> multiple administrative domains. These models may include, for example, a

> generic network topology model for requesting network services as well as

> generic policy models for controlling the communication of status and

> configuration information.

> 2) A set of Yang models defined in 1) to map Yang models of network services

> to network element configurations.

> 3) A set of Yang models that specify how network elements can interact with

> local or remote network controllers (e.g., exchange configuration and status

> information).

> Tina
> ________________________________________

Best regards,
Georgios

From: Chongfeng [mailto:[email-masked]]
Sent: Monday, January 12, 2015 3:28 AM
To: Georgios Karagiannis; sob; Ying Cheng
Cc: junda; diego.r.lopez; Tina TSOU; j.schoenwaelder; [email-masked]; sunqiong
Subject: About the scope of SUPA

Hi all,

Chongfeng Xie

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Georgios Karagiannis
Sent: Wednesday, January 07, 2015 12:57 AM
To: Scott O. Bradner; Ying Cheng
Cc: [email-masked]<mailto:[email-masked]>; DIEGO LOPEZ GARCIA; Tina TSOU; Chongfeng; Juergen Schoenwaelder; [email-masked]<mailto:[email-masked]>
Subject: Re: [Supa] NewVersionNotificationfordraft-cheng-supa-ddc-use-cases-01.txt

Best regards,
Georgios

> Cc: [email-masked]<mailto:[email-masked]>; DIEGO LOPEZ GARCIA; Chongfeng; Tina TSOU;
> Juergen Schoenwaelder; [email-masked]<mailto:[email-masked]>
> Subject: Re: [Supa]
> > On Jan 5, 2015, at 8:03 PM, Ying Cheng <[email-masked]<mailto:[email-masked]>> wrote:
> >
> > Hi Tina, Scott, et al,
> >
> > 收件人： DIEGO LOPEZ GARCIA; Juergen Schoenwaelder; [email-masked]<mailto:[email-masked]>
> > 抄送： Ying Cheng(联通集团联通网络技术研究院); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
> > Chongfeng
> > 主题： Re:
> > Cc: Ying Cheng; [email-masked]<mailto:[email-masked]>; Tina TSOU; [email-masked]<mailto:[email-masked]>;
> > Chongfeng
> > Subject: Re: [Supa]
> > <[email-masked]<mailto:[email-masked]>>
> wrote:
> > > Hi,
> > >
> > >> 抄送： [email-masked]<mailto:[email-masked]>; Tina TSOU; [email-masked]<mailto:[email-masked]>; Chongfeng
> > >> 主题： Re:
> > >> [email-masked]<mailto:[email-masked]>
> > > [email-masked]<mailto:[email-masked]>
> > e-mail: [email-masked]<mailto:[email-masked]>
> > Tel:    +34 913 129 041
> > Mobile: +34 682 051 091
> > [email-masked]<mailto:[email-masked]>
> > [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
_______________________________________________
Supa mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/supa

---

From: "Liushucheng (Will)" <[email-masked]>
Date: Fri, 16 Jan 2015 01:47:14 +0000

Hi Dr. Xie,
I see you’re talking about the link level traffic load adjustment of DC router. Such a scenario may be worth modeling as operators or service providers might need to design flexible adjustment policies for optimizing the throughput of DC router. To emphasized your case in the PS draft, would you please polish the paragraph below so that it can be merged into use case section? Thanks.
Regards,
Will (Shucheng LIU)

From: Supa [mailto:[email-masked]] On Behalf Of Chongfeng
Sent: Monday, January 12, 2015 10:28 AM
To: Georgios Karagiannis; sob; Ying Cheng
Cc: junda; diego.r.lopez; Tina TSOU; sunqiong; j.schoenwaelder; [email-masked]
Subject: [Supa] About the scope of SUPA

Hi all,

Chongfeng Xie

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Georgios Karagiannis
Sent: Wednesday, January 07, 2015 12:57 AM
To: Scott O. Bradner; Ying Cheng
Cc: [email-masked]; DIEGO LOPEZ GARCIA; Tina TSOU; Chongfeng; Juergen Schoenwaelder; [email-masked]
Subject: Re: [Supa] NewVersionNotificationfordraft-cheng-supa-ddc-use-cases-01.txt

Best regards,
Georgios

---

From: Chongfeng <[email-masked]>
Date: Sat, 17 Jan 2015 07:32:20 +0800

Hi,  Dr Liu,

       Based on your suggestion,  I have revised the use case paragraph as below, if you have more suggestions, pls feel free to contact me, thank you!

Operators，such as China Telecom, are testing and implementing the DTS(DC  Traffic  Schedule) schema now. Due to the rapid development of Internet services, each single physical DC can not meet the requirements of an given service system, a general model is that service instances hosted in multiple DCs  collaborate to provide services to end-users，correspondently,inter-DC traffic increase dramatically during the last several years. More specifically, the first driven factor to implement DTS is the scale of services, generally, single physical DC can not provide all the resources for large-scale service at all time，which require the physical DCs to form a virtual DC，so the system can apply for the resource for a ‘single’ virtual DC more flexible and scalable. Another factor is for reliability and security of services, for instance，service instances of an given service located in different DCs will exchange large volume of production data for backup and filing, which may occur at a fixed or non-fixed time of each day. In such a case, an management system monitors traffic volume on the link conveying the exporting traffic of a DC. When the volume exceeds the threshold set by the system, the system designs traffic adjustment system to move the overflowling traffic from that link to another exporting link in order to make sure that the traffic volume on the first link below the threshold. Such scenarios are well worth modeling as operators need to design flexible adjustment policies for optimizing the throughput of DC exporting router.

Chongfeng

From: Liushucheng (Will)
Date: 2015-01-16 09:47
To: Chongfeng
CC: sunqiong; [email-masked]; Georgios Karagiannis
Subject: RE: [Supa] About the scope of SUPA
Hi Dr. Xie,
I see you’re talking about the link level traffic load adjustment of DC router. Such a scenario may be worth modeling as operators or service providers might need to design flexible adjustment policies for optimizing the throughput of DC router. To emphasized your case in the PS draft, would you please polish the paragraph below so that it can be merged into use case section? Thanks.
Regards,
Will (Shucheng LIU)

Hi all,

 
 
Chongfeng Xie

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Georgios Karagiannis
Sent: Wednesday, January 07, 2015 12:57 AM
To: Scott O. Bradner; Ying Cheng
Cc: [email-masked]; DIEGO LOPEZ GARCIA; Tina TSOU; Chongfeng; Juergen Schoenwaelder; [email-masked]
Subject: Re: [Supa] NewVersionNotificationfordraft-cheng-supa-ddc-use-cases-01.txt

 

Best regards,
Georgios