OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tosca message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [tosca] network feature discussion today..


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

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]