Re: [I2nsf] FW: New Version Notification for draft-dunbar-i2nsf-problem-statement-02.txt

["Natale, Bob" <[e-mail]>]

I have to disagree. I will cite just two statements from the “Introduction” text to explain why:

1. The text says:  “In the context of I2NSF, the term ‘Virtual Network Security Function’ is used frequently to emphasize the point that the entities that consume the Network Security functions don’t own or host them.”

That is not the meaning of “virtual” in the generally accepted NFV context. Let me cite four interrelated definitions (verbatim, except that I have “Americanized” the spelling) from ETSI GS NFV 003 V1.2.1 (2014-12):

“Network Function (NF): functional block within a network infrastructure that has well-defined external interfaces and well-defined functional behavior.

Network Functions Virtualization (NFV): principle of separating network functions from the hardware they run on by using virtual hardware abstraction.

Virtualized Network Function (VNF): implementation of an NF that can be deployed on a Network Function Virtualization Infrastructure (NFVI).

Network Functions Virtualization Infrastructure (NFVI): totality of all hardware and software components that build up the environment in which VNFs are deployed.
NOTE: The NFV-Infrastructure can span across several locations, e.g. places where data centers are operated. The network providing connectivity between these locations is regarded to be part of the NFV-Infrastructure.  NFV-Infrastructure and VNF are the top-level conceptual entities in the scope of Network Function Virtualization. All other components are sub-entities of these two main entities.”

As the NFV definition makes clear, “virtualization” in this context is about separating network functions from any specific hardware implementation. That says nothing about “owning” or “hosting” … e.g., a service provider might use the same VNFs that it owns and hosts for its own purposes while at the same time offering them as services to external consumers/subscribers/customers.

2. The text then says: “Those network security functions can be achieved by physical appliances, or by VMs instantiated on servers.”

That statement would be true of “<any> network functions” without the “virtual” qualifier (prefix), per the ETSI definition of “Network Function”. It is not true of “virtual <any> network functions” … per Fig. 1 of ETSI GS NFV-SWA 001 V1.1.1 (2014-12):

[cid:image001.png@01D040E7.B18AEFC0]

So, I have been presuming that this work is about intent-driven policy-based management of security VNFs specifically, per the generally accepted (ETSI) NFV framework. If it’s about NFs in general, then ignore my feedback. However, if it is about VSNFs in particular, the (1) I think the problem statement I-D text needs to refined accordingly and (2) I’d also consider integrating what the above-cited document has to say about “VNF Policy Management”:

“5.3.5 VNF Policy Management

This property describes the ability of a VNF to support dynamic rule-based provisioning and management needed for
automated operational tasks (e.g. scale-in, scale-out, or migration based on threshold crossing). There are some or more
policies for each automatic operation task of VNF. Every VNF will belong to exactly one of the categories below.

• Fully policy based VNF:
- NFV orchestration and management provides full set of provisioning and management policies for this
VNF.

• Not policy based VNF:
- NFV orchestration and management will not provide any provisioning and management VNF policies
for this VNF. VNF will provide policy management by itself.”

You will note that there are two broad use case categories defined there.

Avanti,
BobN

From: I2nsf [mailto:[e-mail]] On Behalf Of Shaibal Chakrabarty
Sent: Thursday, February 05, 2015 12:04 AM
To: Linda Dunbar
Cc: [e-mail]
Subject: Re: [I2nsf] FW: New Version Notification for draft-dunbar-i2nsf-problem-statement-02.txt

Thank you. Looks good. With best regards, shaibal (214-708-6163)

On Wed, Feb 4, 2015 at 10:43 PM, Linda Dunbar <[e-mail]<mailto:[e-mail]>> wrote:
Revised version of i2nsf problem statement has been uploaded.

Comments and suggestions are greatly appreciated.

Linda

-----Original Message-----
From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Wednesday, February 04, 2015 10:41 PM
To: Shaibal Chakrabarty; Linda Dunbar; Christian Jacquenet; Myo Zarny; Christian Jacquenet; Myo Zarny; Shaibal Chakrabarty; Linda Dunbar
Subject: New Version Notification for draft-dunbar-i2nsf-problem-statement-02.txt


A new version of I-D, draft-dunbar-i2nsf-problem-statement-02.txt
has been successfully submitted by Linda Dunbar and posted to the IETF repository.

Name:           draft-dunbar-i2nsf-problem-statement
Revision:       02
Title:          Interface to Network Security Functions Problem Statement
Document date:  2015-02-04
Group:          Individual Submission
Pages:          18
URL:            http://www.ietf.org/internet-drafts/draft-dunbar-i2nsf-problem-statement-02.txt
Status:         https://datatracker.ietf.org/doc/draft-dunbar-i2nsf-problem-statement/
Htmlized:       http://tools.ietf.org/html/draft-dunbar-i2nsf-problem-statement-02
Diff:           http://www.ietf.org/rfcdiff?url2=draft-dunbar-i2nsf-problem-statement-02

Abstract:
   This draft describes the motivation, focused use cases, and the
   problem statement for Interface to Network Security Functions.




Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

_______________________________________________
I2nsf mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/i2nsf