From: Forwarding and Control Element Separation
[mailto:FORCES(_at_)PEACH(_dot_)EASE(_dot_)LSOFT(_dot_)COM] 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