[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 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“.
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
From application perspective, here is the
partial list of dimensions we may want to capture.
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]