Subject: [Supa] about cases from Harvard

From: "Liushucheng (Will)" <[email-masked]>
Date: Thu, 15 Jan 2015 13:13:31 +0000

Hi Scott,

After an offline discussion, I think we should double check with you about two issues in your email below:
1.	> 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
We're not sure why dynamic is the reason that this case is not worth modeling. Could you please elaborate a little bit?

2.	> 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. 
It seems to me it's a "user/organization---app in the cloud---DC" case. In this case there are two kinds of VPN connecting "user/organization---app in the cloud"  and  "app in the cloud---DC". We're not sure 1)which device/organization is accessing the app in cloud. Do you mean individual such as people in their home or one organization such as a university? 2)Which part should be secured by VPN, "user/organization---app in the cloud" or "app in the cloud---DC" or even Both?

Regards,
Will (Shucheng LIU)

> -----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
> 
> 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,
> >
> > 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  程莹
> > China Unicom Network Technology Research Institute 中国联通网络技术
> 研究院
> > Tel: +86-10-68799999-7702
> > Mobile: +86-18601102971
> >
> > 发件人： 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,
> > 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
> > 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.txt
> > >
> > > 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/>
> > <ddc v1.2
> yang.txt>_______________________________________________
> > 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: "Scott O. Bradner" <[email-masked]>
Date: Thu, 15 Jan 2015 08:32:14 -0500

> On Jan 15, 2015, at 8:13 AM, Liushucheng (Will) <[email-masked]> wrote:
> 
> Hi Scott,
> 

the VPNs are initiated by people sitting at their own computers when they want to do so - they could be operating
from their offices or from anywhere they have network connectivity - there is no schedule and no central management 
other than account management (the user needs to have an account with the VPN server to fire up a VPN)

such VPNs are enabled for anywhere from a few minutes to all day

it seems to me that the only thing one could model or monitor is the VPN server itself - not the VPNs
there might be something worthwhile relative to the VPN server but I do not see that modeling a server
fits in the image I had of what SUPA is all about

the centrally configured site-to-site or VPC-to-site VPNs seems to be a better fit

> It seems to me it's a "user/organization---app in the cloud---DC" case. In this case there are two kinds of VPN connecting "user/organization---app in the cloud"  and  "app in the cloud---DC". We'r…

note:  it is not “app in the cloud” - it is a VPC in the cloud that can support one or more apps

and it is not individuals - it is the VPC in the cloud connecting to the data center on campus or vice versa - it is for
applications talking to other applications or databases

and I’m not talking about “accessing the app in the cloud” by users - that happens over the public Internet 
just like with any public facing app

you seem to have misread what I wrote

our current use of VPNs between VPCs in the cloud and the data center is for the purpose I wrote - so that the applications
in the VPC can access services in the campus data center that we do not expose to the public Internet - these VPCs are
managed by the campus networking people and are long lived (essentially permanent) so are something that it would be 
useful to model & manage

Scott

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Thu, 15 Jan 2015 13:41:03 +0000

I agree.
  
Marie-Jose Montpetit, Ph.D.
[email-masked]
@SocialTVMIT

> On Jan 15, 2015, at 8:32 AM, Scott O. Bradner <[email-masked]> wrote:
> 
>

---

From: "Jun Bi" <[email-masked]>
Date: Sat, 17 Jan 2015 22:11:47 +0800

Hi All,

I jump in to introduce a real use case/requirements recently we are discussing in Tsinghua University.

Some of you may visited FIT building in Tsinghua Univ. There are multiple functions in this building, there are a network operation center, a building monitoring network, and many professor having offices in this building but working on test-bed/data for different research projects. In the past, the operation staffs manually set up the VLANs for different users. Right now we have too many projects, then it is becoming very hard to manually set up those different network/testbeds in the shared building LAN, because sometimes one office have multiple rights to access different networks/projects. We are trying to have flexible VPN set up on the shared infrastructure (based on address, VLAN, etc.). In this case, we do hope a controller and the northbound APIs could serve for an APP for operators to flexibly set up the access for different resources.

This is might be a reference..

Thanks,
Jun Bi

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott O. Bradner
Sent: Thursday, January 15, 2015 9:32 PM
To: Liushucheng (Will)
Cc: [email-masked]; Tina TSOU; Chongfeng; Juergen Schoenwaelder; Ying Cheng; [email-masked]; Benoit Claise; Marie-Jose Montpetit; [email-masked]
Subject: Re: [Supa] about cases from Harvard

> We're not sure why dynamic is the reason that this case is not worth modeling. Could you please elaborate a little bit?

the VPNs are initiated by people sitting at their own computers when they want to do so - they could be operating from their offices or from anywhere they have network connectivity - there is no schedule and no central management other than account management (the user needs to have an account with the VPN server to fire up a VPN)

it seems to me that the only thing one could model or monitor is the VPN server itself - not the VPNs there might be something worthwhile relative to the VPN server but I do not see that modeling a server fits in the image I had of what SUPA is all about

and it is not individuals - it is the VPC in the cloud connecting to the data center on campus or vice versa - it is for applications talking to other applications or databases

and I’m not talking about “accessing the app in the cloud” by users - that happens over the public Internet just like with any public facing app

our current use of VPNs between VPCs in the cloud and the data center is for the purpose I wrote - so that the applications in the VPC can access services in the campus data center that we do not expose to the public Internet - these VPCs are managed by the campus networking people and are long lived (essentially permanent) so are something that it would be useful to model & manage

Scott

>> 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
>> 
>> 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”
>> 
>> 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.
>>> 
>> 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.
>> Teleocm, Junda from Google, King from Tencent may have something to 
>> add here.
>>> 6. Cloud broker at DDC
>> 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.
>> 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
>> system/application and controller (called northbound interface). It 
>> is for the traffic optimization between data centers.
>>>> 
>> 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).
>>>> 
>> 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";
>>>>                       }
>>>>           }
>> 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.
>> 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";
>>>>           }
>>>> 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: Marie-Jose Montpetit <[email-masked]>
Date: Sat, 17 Jan 2015 16:55:16 +0000

I like all these use cases but it is still not clear to me why the IETF has to address these problems? Models should be more IRTF?

/mjm

> On Jan 17, 2015, at 9:11 AM, Jun Bi <[email-masked]> wrote:
> 
> Hi All,
>

---

From: Georgios Karagiannis <[email-masked]>
Date: Wed, 21 Jan 2015 08:09:58 +0000

Dear Jun Bi,

In the below paragraph you are talking about the link level traffic load adjustment of DC routers. 
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. 
In order to emphasize your case in the Problem Statement draft, would you please polish the paragraph below so that it can be merged into use case section? 

Best regards,
Georgios

> From: Supa [mailto:[email-masked]] On Behalf Of Jun Bi
> Sent: Saturday, January 17, 2015 3:12 PM
> To: 'Scott O. Bradner'; Liushucheng (Will)
> Cc: [email-masked]; 'Chongfeng'; Tina TSOU; 'Juergen Schoenwaelder'; 'Ying
> Cheng'; [email-masked]; 'Benoit Claise'; 'Marie-Jose Montpetit';
> [email-masked]
> Some of you may visited FIT building in Tsinghua Univ. There are multiple
> functions in this building, there are a network operation center, a building
> monitoring network, and many professor having offices in this building but
> working on test-bed/data for different research projects. In the past, the
> operation staffs manually set up the VLANs for different users. Right now we
> have too many projects, then it is becoming very hard to manually set up those
> different network/testbeds in the shared building LAN, because sometimes one
> office have multiple rights to access different networks/projects. We are
> trying to have flexible VPN set up on the shared infrastructure (based on
> address, VLAN, etc.). In this case, we do hope a controller and the northbound
> APIs could serve for an APP for operators to flexibly set up the access for
> different resources.
> 
> Cc: [email-masked]; Tina TSOU; Chongfeng; Juergen Schoenwaelder; Ying Cheng;
> [email-masked]; Benoit Claise; Marie-Jose Montpetit; [email-masked]
> > We're not sure why dynamic is the reason that this case is not worth
> modeling. Could you please elaborate a little bit?
> 
> the VPNs are initiated by people sitting at their own computers when they want
> to do so - they could be operating from their offices or from anywhere they
> have network connectivity - there is no schedule and no central management
> it seems to me that the only thing one could model or monitor is the VPN
> server itself - not the VPNs there might be something worthwhile relative to
> the VPN server but I do not see that modeling a server fits in the image I had
> of what SUPA is all about
> 
> > It seems to me it's a "user/organization---app in the cloud---DC" case. In
> this case there are two kinds of VPN connecting "user/organization---app in
> the cloud"  and  "app in the cloud---DC". We're not sure 1)which
> device/organization is accessing the app in cloud. Do you mean individual such
> as people in their home or one organization such as a university? 2)Which part
> should be secured by VPN, "user/organization---app in the cloud" or "app in
> the cloud---DC" or even Both?
> 
> and it is not individuals - it is the VPC in the cloud connecting to the data
> center on campus or vice versa - it is for applications talking to other
> applications or databases
> 
> and I’m not talking about “accessing the app in the cloud” by users - that
> happens over the public Internet just like with any public facing app
> 
> our current use of VPNs between VPCs in the cloud and the data center is for
> the purpose I wrote - so that the applications in the VPC can access services
> in the campus data center that we do not expose to the public Internet - these
> VPCs are managed by the campus networking people and are long lived
> (essentially permanent) so are something that it would be useful to model &
> manage
> 
> Scott
> 
> >
> > Regards,
> > Will (Shucheng LIU)
> >