OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC

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

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

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

Hi Frank,   Hemal may have a slightly more definite meaning of “intent”, but  from the conversations, I would guess that our goal is to arrive at features that specify “what” is to be accomplished by some method(s) or other at the network configuration layer(s). Now whether this “what” can be modified by hints as to a more specific way of accomplishing a task is TBD. That will involve deciding how our “abstraction” level relates to various possible implementations. So we will need to confront feature definitions with potential scenarios, to see what abstraction level is useful. Hemal is already helping us understand the degree of abstraction that will allow the network management tools use their preferred approach.   For example, if part of the meaning of a feature is that IP addresses need to be assigned in an ipv4 private range (for the overall application’s internal component internetworking), specifying an OS static address in the /etc directory might work. But there might also be a default for dhcp assignment, and a configuration call to a virtual dhcp service (part of the fabric) to stipulate a range of private IPs to assign…   Some applications will probably work no matter what choice is made for how the assignment is implemented. Other applications may be more dependent on some specific way of getting IPs. For example, a zeroconf application might need to have the autoassign process work, and then use the result to discover neighbors with desired services. In this case, only the link-local addresses would “work,” and the 10/8 or 192.168/16 blocks would not do the job.   We are still deciding how deep in the networking weeds we need to go. In the first meeting, there seemed to be some agreement on scope -- stopping at features expressing a need for a cloud interconnect using a tunnel (needed for public-public, public-private, or private-private cases.)   We also at least tentatively distinguished between the internal component networking for composite apps, and what is needed  for the app environment networking (load balancers, NAT, public DNS changes). The latter is probably not something for which normative definitions will be sought in the near future, even though such configuration will be needed to complete having the running application available to consumers of its services (like when a browser on the internet would access a TOSCA deployed and running sugarcrm ). The consensus seemed to be that the external final touches would not be in scope.   We haven’t really done much with policy yet – really one meeting so far.   Dale Moberg   From: tosca@lists.oasis-open.org [Imailto:tosca@lists.oasis-open.org] On Behalf Of Frank Leymann Sent: Thursday, April 24, 2014 2:15 AM To: Hemal Surti (hsurti) Cc: tosca@lists.oasis-open.org; Dale Moberg 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