Define "data plane" and "control plane"?

[renghardt]

In a discussion around draft-irtf-panrg-questions-10, Spencer suggested that maybe the path properties draft should define "data plane" and "control plane", as it uses these terms in the definition of "entity", and as other PANRG drafts also use these terms.

The path propertiest draft uses these terms only to say the following:

an entity may be on the data plane or control plane Not sure if that makes it critical to define these terms.

The discussion around draft-irtf-panrg-questions-10 has now resulted in using an alternative term for that draft.

If we decide that the path properties draft needs to define "control plane" and "data plane", here's some first thougths:

The path properties draft already cites RFC 7665, which talks about an SFC Control plane and somewhat outlines what it is:

The SFC control plane is responsible for constructing SFPs, translating SFCs to forwarding paths, and propagating path information to participating nodes to achieve requisite forwarding behavior to construct the service overlay.

But RFC 7665 states that "the detailed definition of the SFC control plane is outside the scope of this document." I haven't seen other definitions in an RFC, but that doesn't mean there aren't any. Perhaps the SFC Control plane is too specific for the path properties draft anyways.

Doing a web search, I found more general definitions of these terms, e.g., here:

The control plane is the part of a network that controls how data packets are forwarded — meaning how data is sent from one place to another. The process of creating a routing table, for example, is considered part of the control plane.

In contrast to the control plane, which determines how packets should be forwarded, the data plane actually forwards the packets. The data plane is also called the forwarding plane.

Any opinion?

[renghardt]

On 10/13/21 2:00 PM, Cyrill Krähenbühl wrote:

Regarding the control- and data-plane, I think the cloudflare definition that you cited in the github issue goes in the right direction. I think we just have to be careful to cover all possible (future) PANs, e.g., ALTO, SCION, ... in our definition.

Yep, that's exactly why I'm not sure we even want to define it at all in our draft. And if the definitions are not really needed for our vocabulary, I'd prefer to omit them.

If we do include them, we'll really need to be careful to keep it general enough. The specifics of what constitutes a control or data plane are going to be specific to the used technology.

As we currently only use these words in the entity definition, perhaps we should simply rephrase that part of the definition, e.g.:

OLD: With respect to a given communication, an entity may be on the data plane or control plane

NEW: With respect to a given communication, an entity may participate in controlling how packets are forwarded, e.g., relate to the control plane, or it may actually forward the packets, i.e., relate to the data plane.

Also, differentiating between data- and control-plane might open up additional path properties, e.g., control-plane (traffic) overhead. Although I'm not sure if we really want/should to add more properties...

I don't really want to add more properties.

The properties in the draft are meant as illustrative examples for the presented use cases, so I would only consider adding any properties if they really add value to the use cases, and I don't see that here.