Subject: Re: [Supa] about cases from Harvard

From: "Dacheng Zhang" <[email-masked]>
Date: Wed, 21 Jan 2015 18:04:03 +0800

My last email to the list was blocked. Strange….

发件人:  dacheng de <[email-masked]>
日期:  2015年1月21日 星期三 下午5:51
至:  <[email-masked]>
主题:  re：Re: [Supa] about cases from Harvard

Hi,

I think it should be fine to discuss Models in IETF.  I remember there are
several modeling work being discussed in other IETF groups such as i2rs,
anima.

Cheers

Dacheng

-----Original Message-----
From: Marie-Jose Montpetit [mailto:[email-masked]]
Sent: Sunday, January 18, 2015 12:55 AM
To: Jun Bi
Cc: Scott O. Bradner; Liushucheng (Will); [email-masked]; Tina TSOU;
Chongfeng; Juergen Schoenwaelder; Ying Cheng; [email-masked]; Benoit
Claise; [email-masked]
Subject: Re: [Supa] about cases from Harvard

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
Marie-Jose Montpetit, Ph.D.
[email-masked]
@SocialTVMIT

> On Jan 17, 2015, at 9:11 AM, Jun Bi <[email-masked]> wrote:
> 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
>> On Jan 15, 2015, at 8:13 AM, Liushucheng (Will) <[email-masked]>
>> wrote:
>> 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?
> 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
>> 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?
> 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
>> 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.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/>
>>>> <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
>> _______________________________________________
>> Supa mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/supa
> _______________________________________________
> Supa mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/supa