Subject: anti-plane rant (was RE: draft-anderson-forces-req-00.txt)

From: "tom worster" <[email-masked]>
Date: Sat, 24 Feb 2001 08:12:58 -0500

From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Stern, David L
> 
> Agreed. Is three planes enough? -dave

before a whole bunch more planes are added, could 
we try to figure out what a plane is? this term has 
slipped into the ietf recently and sees a lot of usage 
but i'm unclear what it really means. 

i think it goes back to the good old bisdn reference 
architecture cube that was sliced in three dimensions: 
user, management, and control to produce a user plane, 
a management plane, and a control plane. with a bit of
imagination i can guess what the control plane of the
internet might be and i can almost imagine what its
management plane is. but generalising from this to a 
meaning for "plane" on its own (e.g. without the
"control" in front) is not entirely obvious. and then
adding new plane types like "forwarding plane" and
"data plane" gets me really confused.

for a little while, ccamp was called common control 
and measurement protocols, which i thought i almost 
understood, but the wg web page now says plane instead 
of protocols, as though the wg is working on the design
of only one entity. but this could be a hint!

is plane the collective noun for protocols? as in: 
"gosh, what an extraordinary plane of protocols they 
have built over there!"

that would be fine. but what about sub-system 
functionality? from the systems-engineering point of 
view an ietf protocol is an interface between sub-
systems. but from much of the talk of planes, i get 
the hint that defining a plane involves definitions 
also of sub-system functionality. and that's not 
really ietf turf, is it? (or is it? c.f. rfc1812.)

can anyone provide me the approved summary of the 
ietf's rough consensus on the meaning of "plane"? if
not, should we try to write one down?

c u
fsb