Management Plane vs. Control Plane

[henkbirkholz]

The current definition of the term Management Plane includes the comment “TBD per list; was "Control Plane””.

Is there already a consensus about which term to use? This should be decided soon (and then fixed consistently).

[jarrettlu]

I don't recall seeing discussion or consensus on this. Based on the intended functionalities of this component, I personally like the term Management Plane better. I think you should remove the "TBD..." part. Both the architecture draft and IM draft currently use the term Control Plane. They need the corresponding change to be consistent.

[henkbirkholz]

Additional comments from the SACM list:

On 06/30/2015 10:13 PM, Natale, Bob (RNATALE@mitre.org) wrote:

I am not an active contributor to the SACM work, so discount my input
here accordingly … however, what term to use should not be a matter of
preference … Management Plane and Control Plane have fairly well-defined
meanings in network management architecture (and I’m pretty sure that
Ira is familiar with the applicable references)… which one is SACM
concerned with? … cannot tell from this thread (my bad, for not
researching it further, I know … see opening statement!) … would almost
be willing to bet you probably need both and need to use them properly.

The “New IP” uses them distinctly (and in accordance with their fairly
well-defined meanings) in contexts which encompass but go way beyond
“telecom-centric”.

Avanti,

BobN

On 06/30/2015 11:26 PM, Jarrett Lu (jarrett.lu@oracle.com) wrote:

Hi Bob,

Thanks for the reference to the existing definition of the three planes.
I believe we are using the terms in SACM context, with our own
definitions. For example, in the terminology draft, the term Management
Plane is currently defined as :

   Architectural component providing common functions to all SACM
   participants, including authentication, authorization,
   capabilities mappings, and the like.

Similarly, the architecture draft defines Data Plane Capability as:

Data plane capabilities represent the ability of a Provider or
Consumer to perform a SACM-related task.  For example, the Collector
capability indicates that a Provider can perform Collection tasks;
the Evaluator capability indicates that a Consumer can perform
Evaluation tasks.

While the actual definitions can be refined, the point is that we are
not adhering to the (telecom) industry definitions.

Regards,

Jarrett

On 06/30/2015 11:27 PM, Ira McDonald (blueroofmusic@gmail.com) wrote:

Hi Bob,

Not enough caffeine - certainly Management (by admins) and Control (between
routers) are distinct.

I agree we should use these terms precisely (and not redefine them for
SACM).

"Overview of OAM Tools" (RFC 7276) defines the Data Plane, Control
Plane, and
Management Plane - and is, I imagine, the authoritative IETF reference.

"SDN: Layers and Architecture Terminology" (RFC 7426) expands their
definitions
for SDN, although it also replaces Data Plane with Forwarding Plane and
defines
additional Operational Plane and Application Plane terms.

This web page contrasts the three OAM terms:

http://whatis.techtarget.com/definition/plane-in-networking

Cheers,
Ira

[henkbirkholz]

It remains an open issue to define these terms in the context of SACM. Definitions will probably be very close to existing definitions.

Examples (as a point of reference):

• data plane: the payload coming through (e.g. frames or packets)
• control plane: the rules inside steering the payload (e.g. HTB or OSPF)
• management plane: the interaction from outside steering the rules inside (e.g. NETCONF or sshCLI)

Are these examples considered correct and appropriate enough by the group to provide a basis for further discussion?

Additionally, it could be considered to define interfaces between planes (e.g. a control plane building block could steer a specific data plane building block in a SACM component) and direction of these interfaces (northbound/southbound). If this is out of scope in SACM, a short reference highlighting this in e.g. architecture could be included.

[henkbirkholz]

Terms as defined in RFC 7276 ("An Overview of Operations, Administration, and Maintenance (OAM) Tools")

Data Plane

The data plane is the set of functions used to transfer data in the stratum or layer under consideration [1].
The data plane is also known as the forwarding plane or the user plane.

Control Plane

The control plane is the set of protocols and mechanisms that enable routers to efficiently learn how to forward packets towards their final destination (based on [2]).

Management Plane

The term "Management Plane", as described in [3], is used to describe the exchange of management messages through management protocols (often transported by IP and by IP transport protocols) between management applications and the managed entities such as network nodes.

[1] ITU-R/ITU-T, "ITU-R/ITU-T Terms and Definitions", 2013, http://www.itu.int/pub/R-TER-DB.
[2] Bonaventure, O., "Computer Networking: Principles, Protocols and Practice", 2008.
[3] Farrel, A., "Inclusion of Manageability Sections in Path Computation Element (PCE) Working Group Drafts", RFC 6123, February 2011.

[jimsch]

I do not know if there is any benefit at this point to separating the control plane and the management plane in the terms that have been summarized in this issue so far.

I don't know that I have a preference between the two terms, however in terms of what we have discussed so far in the architecture we have be looking at what is deemed to be control plane functions. Protocols like broker protocol and agents like access control points are doing things "inside" of the system and not external terms.

Functions like publishing guidance might be termed as management in terms of what is discussed, but I tend to look at that as just one more piece of data that is moving around the system. It does not matter to me how it gets published into the system at this point.

[llorenzin]

Per the 1/25 virtual interim discussion, I suggest dropping the quoted RFC6192 content in the Control Plane and Data Plane entries and revising those entries to something along the lines of:
"In contrast to other industry usage (e.g. RFC6192), the (control|data) plane in the SACM context is an architectural component..."

[henkbirkholz]

addressed in the draft.