Folks,
I think this comment would have been fine, and I guess I supported it if
it would have been here two years ago. As it is now I think there are to
much water under the bridges, and actually to many documents involved.
We have a common usage of "North Bound" or "Northbound" and South Bound"
or Southbound". The pain in changing is much greater than the gain.
However, I would support adding text to the terminology section like
this:
North Bound Interface - the interface between the client and the
controller
South Bound Interface - the interface between the controller and the NSF
/Loa
On 2016-06-26 04:02, John Strassner wrote:
Hi Linda,
During the I2NSF early stage (before the WG was created), "capability
interface" was used to represent the interface between controller <->
NSF, and "service interface" was used to represent the interface between
the Client <-> controller. ____
<jcs>
The term "capability interface" doesn't bother me. However, I don't
think that we are using it to its full potential - see below.
The term "client interface" does bother me, because
1) to me, it implies a client-server architecture (or a 3-tier
architecture on a stretch), and I don't understand why we should be
limited to that
2) what is the client? To me, a client is a host. Aren't we talking
about the application here? The examples in your figure are arguably
SERVERS,
not CLIENTS. :-)
</jcs
As many people use the terminologies loosely, the "Capability Interface"
being interchangeably used with "Capability Layer", and "Service
Interface" being interchangeably used with "Service Layer". ____
<jcs>
Warning, this is probably just me, but...
...I do NOT like "layers", because abstractions should work for
everything, not just sometimes. Look at our "layers" - we repeatedly
violate the true notion of a layer (e.g., MPLS). Look at all of the
"inter-layer" compatibility problems we've had over the years. Why do we
need to use layers in I2NSF? I would strongly argue to use "interface";
if that is not acceptable, then choose a different term (e.g., planes)
that does not have the traditional limitations of layers.
</jcs>
The I2NSF Terminology Draft has defined the "Capability Layer"
(independent of which interface to the controller) for exposing the
capability of a domain (over Client Facing Interface), or for exposing
the capability of a NSF (over the NSF Facing Interface). ____
By this definition, ECA Policy’s "Event" capability can be discovered
independently from the "Condition" capability, or "Action" capability.
<jcs>
Sorry, I disagree.
Events, conditions, and actions are NOT capabilities. Capabilities are
defined in the Capabilities Draft as:
Capabilities are functions that NSFs can perform. This interface
is used to advertise, select, and activate capabilities of selected
NSFs in a vendor-independent manner.
Put another way, Capabilities are used to define functions that MAY be
used. There is no guarantee that they will be actually used.
Furthermore, Events, Conditions, and Actions are used to construct an
ECA policy rule. Events, Conditions, and Actions are types of Boolean
statements (at least in ECA rules) and have nothing to do with Capabilities.
While you MAY be able to relate a rule to Capabilities, they are two
completely separate things.
</jcs>
Therefore, continue using the “Capability Interface” can cause more
confusion in the future as its sound is too close to the “Capability
layer”.
<jcs>
Agree. So let's get rid of Capability **layer**. It isn't a layer,
because...
...wait for it...
...Capabilities could be used to describe NSF functions as well as
Controller functions. Thus, there is no "layer" in the classical
definition of the term "layer".
</jcs>
__ __
Therefore, we are asking people to state which of the following options
should be used:____
__ __
__1. __Use “Client Facing Interface” for "Client <-> controller";
and “NSF Facing Interface” for "controller <-> NSF", ____
__2. __Use “Controller North Bound Interface” for "Client <->
controller"; and “Controller South Bound Interface” for “controller <->
NSF", or ____
__ __
Or you can provide a better option.
<jcs>
I choose option 3. :-)
The problem with "Client-Facing Interface" is that I'm not sure what a
"Client" is in NSF.
NSF-Facing Interface is OK; my problem is, why are we introducing Yet
Another Term?
The problem with Northbound and Southbound is that there is no clear
"north" and "south" here. Look at all of the projects that propose
various data models at both the device interface level AND the network
management application layer. So tell me, which is "south" here? :-)
Now, as for option 3, I'm thinking about it. However, I do think that
you have spotted an important inconsistency, so let's take time to fix
it and not rush into rash decisions.
</jcs>
best regards,
John
On Thu, Jun 23, 2016 at 3:31 PM, Linda Dunbar <[email protected]
<mailto:[email protected]>> wrote:
I2NSF WG:____
__ __
Need your opinion for a good name to represent “Client Facing
Interface” and “NSF Facing Interface” of the I2NSF reference model: ____
+-----------------------------------------------------+____
| I2NSF Client
|____
| E.g. Overlay Network Mgnt, Enterprise network Mgnt
|____
| another network domain’s mgnt, etc.
|____
+----------+------------------------------------------+____
|____
| Client Facing Interface ____
|____
+-----+---------------+ ____
|Network Operator mgmt|
+-------------+____
| Security Controller | < --------- > |
Developer’s |____
+----------+----------+ Registration | Mgnt
System |____
| Interface
+-------------+____
| ____
| NSF Facing Interface____
|____
+----------------------+----------------------------+____
| |____
| |____
+---+--+ +------+ +------+ +--+---+____
+ NSF-1+ ------- + NSF-n+ +NSF-1 + ----- +NSF-m + .
. . ____
+------+ +------+ +------+ +------+____
__ __
Vendor A Vendor B____
__ __
__ __
During the I2NSF early stage (before the WG was created),
"capability interface" was used to represent the interface between
controller <-> NSF, and "service interface" was used to represent
the interface between the Client <-> controller. ____
__ __
As many people use the terminologies loosely, the "Capability
Interface" being interchangeably used with "Capability Layer", and
"Service Interface" being interchangeably used with "Service Layer".
____
__ __
The I2NSF Terminology Draft has defined the "Capability Layer"
(independent of which interface to the controller) for exposing the
capability of a domain (over Client Facing Interface), or for
exposing the capability of a NSF (over the NSF Facing Interface). ____
By this definition, ECA Policy’s "Event" capability can be
discovered independently from the "Condition" capability, or
"Action" capability. ____
__ __
Therefore, continue using the “Capability Interface” can cause more
confusion in the future as its sound is too close to the “Capability
layer”. ____
__ __
Therefore, we are asking people to state which of the following
options should be used:____
__ __
__1. __Use “Client Facing Interface” for "Client <->
controller"; and “NSF Facing Interface” for "controller <-> NSF", ____
__2. __Use “Controller North Bound Interface” for "Client <->
controller"; and “Controller South Bound Interface” for “controller
<-> NSF", or ____
__ __
Or you can provide a better option. ____
__ __
Thanks, Linda ____
__ __
__ __
_______________________________________________
I2nsf mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/i2nsf
--
regards,
John
_______________________________________________
I2nsf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2nsf
_______________________________________________
I2nsf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2nsf
