Hi John,
Thanks for the note about the capability layer. I understand your point and I feel that abstraction may be more precise than abstraction layer. In your second definition of "Capability Layer", what can be the "set of features available to the Controller", for eg., in IDS or Firewall. I visualized the capability interface as the commanding interface which gives a set of instructions to the NSFs on what to do and receives feedback from the NSFs once the set of instructions are implemented. Regards, Rajasekhar ________________________________ From: John Strassner <[email protected]> Sent: Sunday, June 19, 2016 10:17:42 PM To: Ganduri, Rajasekhar Cc: Linda Dunbar; [email protected]; DIEGO LOPEZ GARCIA ([email protected]); Susan Hares Subject: Re: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00 Hi Rajasekhar, please see my last reply to Linda. For me, I don't think that an abstraction **layer** makes sense. A layer should be used to abstract a common set of functionality - otherwise, you have a set of abstractions of different functions that mean different things. best regards, John On Sat, Jun 18, 2016 at 12:07 AM, Ganduri, Rajasekhar <[email protected]<mailto:[email protected]>> wrote: Hey, I am a novice in I2NSF IETF group and its capabilities but I am a regular follower of the current activities of I2NSF. According to my understanding, the term "abstraction layer" is used to specify that the end user/client need not have the complete visibility of the working or implementation of how the I2NSF controller communicates with the NSFs. This is what interested me in I2NSF, as this opens up to a new set of end users who need not have complete understanding of how a network operates. I implemented this in my research, where a web application tool is built that can be used by "any" end user to give simple natural language inputs through Interface1 (Service Layer) to the controller (or Openstack Cloud controller in my case) and the controller translates and transfers the security commands to the IDS and firewalls through Interface2(Capability layer). The way in which the controller transfers to the NSFs is hidden from the end user (or the end user need not know, details being hidden or abstracted) but the end user will have the authority over Interface2 in his/her own network. Please let me know if I understood wrongly. Thanks and Regards, Rajasekhar ________________________________ From: Linda Dunbar <[email protected]<mailto:[email protected]>> Sent: Friday, June 17, 2016 4:10 AM To: John Strassner Cc: [email protected]<mailto:[email protected]>; DIEGO LOPEZ GARCIA ([email protected]<mailto:[email protected]>); Susan Hares Subject: Re: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00 John, My thinking maybe too simplistic. I picture a “Controller” having two ports, - one port connecting to clients (which can be another domain controller or Overlay network controller), interface from this port is “Service layer interface” - another port connecting to NSFs, the interface from this port is “capability layer interface”. So I thought that the Service Layer interface is the North Bound interface to the Controller, the capability interface is the south bound to the controller. What extra meaning does it carry with the wording “abstraction Layer” ? Capability Layer: Defines an abstraction layer that exposes a set of {features that are available from a managed entity} of the I2NSF system. Thank you. Linda From: John Strassner [mailto:[email protected]<mailto:[email protected]>] Sent: Thursday, June 16, 2016 12:58 AM To: Linda Dunbar; John Strassner Cc: Susan Hares; DIEGO LOPEZ GARCIA ([email protected]<mailto:[email protected]>); [email protected]<mailto:[email protected]> Subject: Re: questions about some terminologies defined by draft-ietf-i2nsf-terminology-00 HI Linda, I don't see the conflict in the two definitions. If I substitute the first (within braces) into the second, I get: Capability Layer: Defines an abstraction layer that exposes a set of {features that are available from a managed entity} of the I2NSF system. When I look at the Charter's Capability Layer, I think we're still OK - the Charter "...specifies how to control and monitor NSFs at a functional level...", and Capabilities (the features that are available) are essential for planning how to control and monitor NSFs. Features (i.e., capabilities) are independent of interface (northbound or southbound). Would you like us to add that point to the terminology I-D? best regards, John On Wed, Jun 15, 2016 at 8:40 AM, Linda Dunbar <[email protected]<mailto:[email protected]>> wrote: Dear Authors: The term “Capability Layer” defined by the “draft-ietf-i2nsf-terminology-00” carries different meaning than the “Capability Layer” used by the I2NSF charter. “draft-ietf-i2nsf-terminology-00”: Capability: Defines a set of features that are available from a managed entity (see also I2NSF Capability). Capability Layer: Defines an abstraction layer that exposes a set of capabilities of the I2NSF system. I2NSF Charter: I2NSF will specify interfaces at two functional levels for the control and monitoring of network security functions: The I2NSF Capability Layer specifies how to control and monitor NSFs at a functional implementation level. The term "Functional Implementation" is used to emphasize that the rules (for control and monitor) of NSFs have to be implementable by most NSFs. I2NSF will standardize a set of interfaces by which a security controller can invoke, operate, and monitor NSFs. The I2NSF Service Layer defines how clients' security policies may be expressed to a security controller. The controller implements its policies according to the various capabilities provided by the I2NSF Capability Layer. The I2NSF Service Layer also allows the client to monitor the client specific policies. If we use the definitions by the “draft-ietf-i2nsf-terminology-00”, we should create a different terminology to represent the “South bound Interface” between Controller and NSF. Thanks, Linda -- regards, John -- regards, John
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
