Re: [tosca] network feature discussion today..

["Hemal Surti (hsurti)" <hsurti@cisco.com>]

Hi Frank,

Absolutely. Apologize if it came across condescending. However, given Network requires more complex and in-depth definition compared to compute and storage, I just wanted to reiterate the tenets. I feel that it will be easy to go down slippery slop of being prescriptive in network specifications. my 2 cents :)

As for the differences, ‘Declarative' deals with level of abstraction aspect Vs, 'Intent based' deals with inference aspect of the network specification. Policies are the constraints user can put on achieving the intent.

I will have to miss today’s TOSCA meeting due to some critical deliverables, but I plan to join regularly starting next week forward. Please, feel free to continue discussion via email. 

Thanks,

Hemal

From: Frank Leymann <Frank.Leymann@iaas.uni-stuttgart.de>
Date: Thursday, April 24, 2014 at 5:15 AM
To: Cisco Employee <hsurti@cisco.com>
Cc: "tosca@lists.oasis-open.org" <tosca@lists.oasis-open.org>, "dmoberg@axway.com" <dmoberg@axway.com>
Subject: Re: [tosca] network feature discussion today..

Hi Hemal,

I assume the the requirements on the specification (being declarative etc) does not only apply to networking features but to other types of features too: correct?  I.e. the goal is to also have storage, compute,… features be handled declaratively, abstracted from the implementation etc.

What is the difference between being „declarative“ and „intend based“?  Furthermore, being „policy based“ is some sort of mechanism to specify the „intend“, i.e. assuming a policy mechanism is predetermining a way to achieve „intend based“.

Gruss/Regards,
Frank

Am 24.04.2014 um 02:25 schrieb Hemal Surti (hsurti) <hsurti@cisco.com>:

Hi Dale/Derek,

Based our Network feature discussion today, here are some thoughts around describing connectivity.

Specification needs to be

• Declarative
• Intent based 
• Implementation abstraction
• Policy Based

From application perspective, here is the partial list of dimensions we may want to capture.

• Type of connection
• Network Classification of connection
• Source End point requirements
• Destination end point capabilities
• attributes of connection
• Quality of connection
• Security policies adherence

In order to achieve the right balance in abstraction, we may have to work from both ends. 

1> upwards from network component requirements (firewall, tunnel, LB, NAT, Domain, routing…) on one end.

2>  application modeling requirements (protocol, quality, security, availability, resiliency…) from other end. 

I can provide more details during our next session.

Thanks,

Hemal