From: Forwarding and Control Element Separation [mailto:[EMAIL PROTECTED]] 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
