Subject: Re: [Supa] NewVersionNotificationfordraft-cheng-supa-ddc-use-cases-01.txt

From: Ying Cheng <[email-masked]>
Date: Tue, 6 Jan 2015 09:03:26 +0800

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.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/>
>
> _______________________________________________
> 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

---

From: "Scott O. Bradner" <[email-masked]>
Date: Mon, 5 Jan 2015 20:10:56 -0500

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,
>

---

From: "Liushucheng (Will)" <[email-masked]>
Date: Tue, 6 Jan 2015 03:30:13 +0000

Hi Scott,

These are practical cases and solid inputs. I'm interested in the 'between organizations' case. Are you implying that those DCs that belong to different organizations, multiple trust zones in your case are controlled by to more than one, even multi-level controllers?

Regards,
Will (Shucheng LIU)

> From: Supa [mailto:[email-masked]] On Behalf Of Scott O. Bradner
> Sent: Tuesday, January 06, 2015 9: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
> 
> > 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  程莹
> > 抄送： Ying Cheng(联通集团联通网络技术研究院); [email-masked];
> [email-masked];
> > Chongfeng
> > 主题： Re:
> > 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
> > 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,
> > >
> > >> 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
> > >>       list vpnService {
> > >>           key "vpnName";
> > >>           leaf vpnName {
> > >>               description "VPN name.";
> > >>               type string;
> > >>               mandatory "true";
> > >>           }
> > >>           leaf vlanId {
> > >>               description "vlan id.";
> > >>               type uint16{
> > >>                           range "1 .. 4094";
> > >>                       }
> > >>           }
> > >>             //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.
> > >>       list specifyFlowPath {
> > >>           key "vpnName";
> > >>           leaf vpnName {
> > >>               description "VPN name.";
> > >>               type string;
> > >>               mandatory "true";
> > >>           }
> > >> 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
> > >> --
> > 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: Georgios Karagiannis <[email-masked]>
Date: Tue, 6 Jan 2015 16:57:01 +0000

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

> Sent: Tuesday, January 06, 2015 2:11 AM
> To: Ying Cheng
> Cc: [email-masked]; DIEGO LOPEZ GARCIA; Chongfeng; Tina TSOU; Juergen
> Schoenwaelder; [email-masked]
> 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
> 
> 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  程莹
> > 2014, at 09:14 , Juergen Schoenwaelder <[email-masked]>
> wrote:
> > > Hi,
> > >
> > >> 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
> > >>               //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";
> > >>                       }
> > >>           }
> > >>             //management system/ application requires controller to
> adjust the bandwidth of VPN to optimize the traffic when the bandwidth
> > >>               //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
> 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.
> 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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 6 Jan 2015 18:03:02 +0100

On Thu, Dec 25, 2014 at 03:08:43PM +0800, Ying Cheng wrote:
> 
> 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. 
>

Hi,

I think we need to move to a state where YANG models satisfy some
minimum requirements in terms of correctness and completeness and so
on. I believe people writing YANG models should use pyang from the
very beginning to make sure things are correct (as far as pyang can
check) and follow IETF guidelines (pyang -ietf). Writing data models
is like writing code and sending out code for review and comment that
does not even pass a compiler is - well not a good way to build up
reputation. To be constructive, I have edited the YANG fragment that
passes pyang (but not pyang -ietf). I did not change the model itself
and there are many questions to be asked about it as well. But anyway,
first look at and fix all my xxx comments.

I also strongly suggest that people write XML instance documents as
examples while writing the YANG model. Set things up such that the XML
examples can be validated against the YANG model. If the XML examples
do not look nice, clean, and simple, tweak the YANG model until they
do. I somehow doubt that XML examples will look nice, clean, and
simple for this data model fragment.

/js

PS: I still believe there is nothing DDC specific and there should not
    be something that is DDC specific. If something DDC really is
    needed, it should be an augmentation of a basic VPN service
    management model.

---

From: Ying Cheng <[email-masked]>
Date: Mon, 12 Jan 2015 10:30:48 +0800

Hi Juergen,

Thanks for your guide and comments. The updated draft for ddc yang model is attached. Please kindly review it.

BR,
Ying

2015-01-12 

Ying CHENG  程莹

发件人： Juergen Schoenwaelder 
发送时间： 2015-01-07  01:03:15 
收件人： Ying Cheng(联通集团联通网络技术研究院) 
抄送： Tina TSOU; Benoit Claise; [email-masked]; [email-masked]; [email-masked]; Chongfeng 
主题： Re: [Supa]NewVersionNotificationfordraft-cheng-supa-ddc-use-cases-01.txt 
 
Hi,

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 12 Jan 2015 10:34:55 +0100

> Thanks for your guide and comments. The updated draft for ddc yang model is attached. Please kindly review it.

- Remove the version number from the module name.
- Make sure the module passes pyang --ietf.
- Indent description clauses properly
- The reference of a revision usually points to the document where the
  yang module is published. I fail to understand the reference to
  RFC4364 and RFC7277.
- Multiple top-level nodes are not allowed in IETF module; as
  mentioned before, write instance documents and rethink the
  nesting structure.
- What is the value of vpnType if connectionType is native IP?
- As mentioned before, use units for things like bandwidth or latency
  or even better define suitable typedefs.
- I do not understand srcIp-prefix, destIp-prefix - why do you not
  use inet:ip-prefix?
- The preferred naming style is hyphenated-words-like-this. You use
  camlcase, sometimes mixed with hyphens, sometimes capitalized words,
  it is all inconsistent. Make it consistent and the preferred
  naming style is hyphenated-words-like-this.
- Why do you not use inet:port-number?

I do not really understand what the create... containers are good
for. Everything with 'config true' can be created. And why is the VPN
related information split into multiple lists all indexed by vpnName?
Rethink the structure needed and as mentioned before it will help to
write down example XML snippets (and use pyang to make sure that the
examples validate against the schema).

/js

---

From: Ying Cheng <[email-masked]>
Date: Tue, 13 Jan 2015 23:19:36 +0800

Hi Juergen,

Thanks for your prompt response. Attached please kindly review the updated version based upon your comments and questions.

BR,
Ying

2015-01-13 

Ying CHENG  程莹

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

---

From: "Liushucheng (Will)" <[email-masked]>
Date: Wed, 28 Jan 2015 13:57:28 +0000

Hi Ying, Juergen and the group,

I find this thread valuable for this mailing list and worth digging out and try to revisit.  Before typing comments and coping the long code, I’d like to ask a quick question: What’s the relationship between the ietf-supa-ddc.yang and models in https://datatracker.ietf.org/doc/draft-zaalouk-supa-configuration-model/ ? Should ietf-supa-ddc.yang be adopted into the future version of the aforementioned draft or anywhere else?

I reviewed the attached file and believe that “specify-flow-paths” and “detourPolicys” can be merged together as they shared a lot in common. So I’m proposing to use

module: ietf-supa-ddc

   +--rw ddc-operation

      +--rw create-ddc-Services

      |  +--rw ddc-service* [tenant-name]

      |     +--rw tenant-name                   string

      |     +--rw dc-name*                      string

      |     +--rw tenant-network-id*            string

      |     +--rw connection-type-between-dc?   enumeration

      +--rw create-vpn-instances-for-ddc

      |  +--rw vpn-instance* [vpn-name]

      |     +--rw vpn-name          string

      |     +--rw vlan-id?          uint16

      |     +--rw dc-information* [dc-name]

      |     |  +--rw dc-name           string

      |     |  +--rw interface-name?   string

      |     +--rw vpn-type?         enumeration

      |     +--rw bandwidth?        uint32

      |     +--rw latency?          uint32

      +--rw optimize-traffic-Services

      |  +--rw optimize-traffic-service* [vpn-name]

      |     +--rw vpn-name     string

      |     +--rw bandWidth?   uint32

      |     +--rw latency?     uint32

      +--rw specify-flow-paths

         +--rw specify-flow-path* [vpn-name]

            +--rw vpn-name     string

            +--rw vpn-type?    enumeration

            +--rw flow-name?   string

            +--rw threshold?   uint32  //this one is added from detour part

            +--rw pass-node*   string

            +--rw bypass-node* string //this one is added from detour part

instead of the old one below

module: ietf-supa-ddc

   +--rw ddc-operation

      +--rw create-ddc-Services

      |  +--rw ddc-service* [tenant-name]

      |     +--rw tenant-name                   string

      |     +--rw dc-name*                      string

      |     +--rw tenant-network-id*            string

      |     +--rw connection-type-between-dc?   enumeration

      +--rw create-vpn-instances-for-ddc

      |  +--rw vpn-instance* [vpn-name]

      |     +--rw vpn-name          string

      |     +--rw vlan-id?          uint16

      |     +--rw dc-information* [dc-name]

      |     |  +--rw dc-name           string

      |     |  +--rw interface-name?   string

      |     +--rw vpn-type?         enumeration

      |     +--rw bandwidth?        uint32

      |     +--rw latency?          uint32

      +--rw optimize-traffic-Services

      |  +--rw optimize-traffic-service* [vpn-name]

      |     +--rw vpn-name     string

      |     +--rw vpn-type?    enumeration

      |     +--rw bandWidth?   uint32

      |     +--rw latency?     uint32

      +--rw specify-flow-paths

      |  +--rw specify-flow-path* [vpn-name]

      |     +--rw vpn-name     string

      |     +--rw vpn-type?    enumeration

      |     +--rw flow-name?   string

      |     +--rw node*        string

      +--rw detourPolicys

         +--rw detourPolicy* [vpn-name]

            +--rw vpn-name                   string

            +--rw flow-name?                 string

            +--rw threshold?                 uint32

            +--rw source-ip?                 inet:ip-address

            +--rw source-ip-prefix?          inet:ip-prefix

            +--rw destination-ip?            inet:ip-address

            +--rw destination-ip-prefix?     inet:ip-prefix

            +--rw source-port-number?        inet:port-number

            +--rw destination-port-number?   inet:port-number
                                   +--rw bypass-node*               string

Therefore the corresponding code can be changed to:

container specify-flow-paths {

    description

      "To improve the bandwidth utilization (or reduce the cost,

       or other reason) and miligate traffic congestion,management

       system/ application requires controller to adjust certain

       flows to pass/bypass certain nodes(or links), when, e.g.,

       bandwidth utilization exceed certain threshold. 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 specify-flow-path {

      key "vpn-name";

      description

        "The list of VPN and flow that need to be adjusted in

         specific paths. So as to optimizing traffic in the links

         that are between data centers.";

      leaf vpn-name {

        type string;

        mandatory true;

        description

          "Indicates the name of VPN that the adjusted flow belongs

           to. A VPN instance is identified by vpn-name. It should

           be one of the created VPN instance names";

      }

      leaf vpn-type {

        type enumeration {

          enum L2VPN {

            description "L2VPN";

          }

          enum L3VPN {

            description "L3VPN";

          }

        }

        description

             "Indicates the type of VPN instance that the adjusted flow belongs to. L2VPN or L3VPN";

      }

      leaf flow-name {

        type string;

        description

          "The name of the adjusted flow. So as to tell the

           Controller which flow should be adjusted";

      }

      leaf threshold {

        type uint32;

        description

          "The bandwidth threshold of the link. If the link usage

          is greater than the threshold, the specified node will

          be by bypassed.";

      }

      leaf-list pass-node {

        type string;

        description

          "List of nodes that the adjusted flow needs to pass.

           So as to adjust the flow path between data centers.";

      }

      leaf-list bypass-node {

        type string;

        description

          "List of nodes that the adjusted flow needs to bypass

           if the link usage is greater than the threshold.

           So as to adjust the flow path between data centers.";

      }

    }

  }

Regards,
Will (Shucheng LIU)

From: Supa [mailto:[email-masked]] On Behalf Of Ying Cheng
Sent: Tuesday, January 13, 2015 11:20 PM
To: Juergen Schoenwaelder
Cc: [email-masked]; Tina TSOU; Chongfeng; kinghe; Benoit Claise; [email-masked]
Subject: Re: [Supa] NewVersionNotificationfordraft-cheng-supa-ddc-use-cases-01.txt

Hi Juergen,

BR,
Ying

2015-01-13
抄送： [email-masked]<mailto:[email-masked]>; Chongfeng; Tina TSOU; [email-masked]<mailto:[email-masked]>; Benoit Claise; [email-masked]<mailto:[email-masked]>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 28 Jan 2015 18:48:16 +0100

> I find this thread valuable for this mailing list and worth digging out and try to revisit.  Before typing comments and coping the long code, I’d like to ask a quick question: What’s the relationsh…

I can't tell because of a general lack of descriptions what all the
proposed data nodes are supposed to do. I am old style - I can't infer
behaviour from a name and a type. We need to raise the bar a bit for
the YANG models:

- Ideally, they should all pass pyang --ietf.
- They should use meaningful data types.
- They should use meaningful module and data node names.
- They should not define arbitrary constraints without a reason.
- They should not repeat things that are default in YANG.
- They should support both IPv4 and IPv6.

There is also RFC 6087 to read and follow.

/js

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 28 Jan 2015 13:00:08 -0500

> Le 2015-01-28 à 12:48, Juergen Schoenwaelder <[email-masked]> a écrit :
> 

agreed. but I just want to say here that supa is not even a BOF, nor a wg. So while we should drive for the best specifications, I would be ok with a lower bar than, for example, a wg document. That does not say to not do it better, but…

Marc.