Subject: [Sdn] Thoughts on Defining control and Management Planes

From: Shivleela Arlimatti <[email-masked]>
Date: Thu, 7 Nov 2013 22:23:08 +0800

after reading all this really we beginners get confused.  If we remove
control plane  and redefine it as centralized manager? according to me if
we do this control plane will be in the control of end users...Then it may
be difficult to manage the network because management layer applications
are different as control plane applications.

Shivaleela Arlimatti
Research scholar,
InterNetworks Research Lab, CAS
UUM Sintok, Malaysia.

On Thu, Nov 7, 2013 at 4:27 PM, <[email-masked]> wrote:

> If you have received this digest without all the individual message
> attachments you will need to update your digest options in your list
> subscription.  To do so, go to
>
> https://www.irtf.org/mailman/listinfo/sdn
>
> Click the 'Unsubscribe or edit options' button, log in, and set "Get
> MIME or Plain Text Digests?" to MIME.  You can set this option
> globally for all the list digests you receive at this point.
>
>
>
> Send sdn mailing list submissions to
>         [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.irtf.org/mailman/listinfo/sdn
> or, via email, send a message with subject or body 'help' to
>         [email-masked]
>
> You can reach the person managing the list at
>         [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of sdn digest..."
>
>
> Today's Topics:
>
>    1. Re: Thoughts on Defining control and Management Planes
>       (Kireeti Kompella)
>    2. Re: Thoughts on Defining control and Management Planes
>       (Robert Raszuk)
>    3. Re: Thoughts on Defining control and Management Planes
>       (Russ White)
>    4. Re: Thoughts on Defining control and Management Planes
>       (Robert Raszuk)
>    5. Re: Thoughts on Defining control and Management Planes
>       (Russ White)
>    6. Re: Thoughts on Defining control and Management Planes
>       (Robert Raszuk)
>    7. Re: Thoughts on Defining control and Management Planes
>       (Pedro Martinez-Julia)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 6 Nov 2013 20:13:13 -0800
> From: Kireeti Kompella <[email-masked]>
> To: Robert Raszuk <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Subject: Re: [Sdn] Thoughts on Defining control and Management Planes
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=us-ascii
>
> On Nov 6, 2013, at 14:52 , Robert Raszuk <[email-masked]> wrote:
>
> > You centralize what you must and distribute what you can.
>
> Right on!  (again!)
>
> The difficulty for some folks (like me) is to drag our heads out of
> distributing everything on principle, and understand when centralization is
> a must.
>
> ------------------------------
>
> Message: 2
> Date: Thu, 7 Nov 2013 06:36:03 +0100
> From: Robert Raszuk <[email-masked]>
> To: Kireeti Kompella <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Subject: Re: [Sdn] Thoughts on Defining control and Management Planes
> Message-ID:
>         <CA+b+ER=
> [email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi Kireeti,
>
> >> You centralize what you must and distribute what you can.
> >
> > Right on!  (again!)
> >
> > The difficulty for some folks (like me) is to drag our heads out of
> > distributing everything on principle, and understand when centralization
> > is a must.
>
> Indeed ! And as you know me I am not of much help here .. been to long
> around distributed protocols and saw how nicely they operate under
> very different circumstances to just turn 180 degrees around and say
> they are all *legacy* just because someone said so.
>
> And to go a bit more maybe it is worth to spend a moment to see what
> the issue is ? Folks complain running BGP is so complex .. developing
> it even worse. Well for those there is really well done BGP
> implementation of OpenContrail which those guys are free to use. I
> would consider at this point of time this topic as checked.
>
> Then we see enemies of IGPs .. OSPF and ISIS maybe even TRILL ...
> perhaps someone needs to found efforts to deliver solid open source of
> those components as well .. maybe Quagga will catch up .. maybe we
> will see other options .. but then one can take ODM box put Cumulus OS
> on it and run it as seems fit.
>
> If you run those on the box you can already claim SDN ! After all both
> data plane and contrail plane (ooops control plane) would be
> completely decoupled and even coming from many sources.
>
> Such modern new NG network or old fashioned legacy network can then
> focus  on central PCE deployment for path computation, could deliver
> customized services like transport aware VPNs, could shift most
> services to data centers etc ... and this is where we should be
> looking for SDN killer apps. Not upside down from the Broadcom/Marvell
> ASICs up the stack. That's like climbing the ladder from the tip of
> the tree ;)
>
> Best,
> R.
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 7 Nov 2013 00:59:37 -0500
> From: "Russ White" <[email-masked]>
> To: "'Kireeti Kompella'" <[email-masked]>,  "'Robert
>         Raszuk'" <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Sdn] Thoughts on Defining control and Management Planes
> Message-ID: <[email-masked]>
> Content-Type: text/plain;       charset="us-ascii"
>
>
> > The difficulty for some folks (like me) is to drag our heads out of
> distributing
> > everything on principle, and understand when centralization is a must.
>
> Of course --but that doesn't really help us determine a solid model to
> use... The point here is to find a model that can be used to accurately
> describe interactions and protocols at the device level, so we can sort and
> classify the APIs and protocols needed at this level, then figure out how
> those protocols and APIs relate to services and the network as a whole.
>
> I agree there is a need for higher level models to show how services
> interact, and how the network works as a whole, but we can't simply ignore
> that there are physical devices someplace connected to tangible wires that
> must switch real packets between two specific destinations in the network.
> If we can't describe what the pieces of that device are and how things
> outside that device interact with it, then all the services and network
> models in the world aren't going to get us from an architecture to actually
> making packets flow from point a to point b. One of the problems with the
> SDN space is we always start with the ocean and a thousand uncoordinated
> matches. Let's try with a single small cup and a large stove instead.
>
> So the services and network models are beautiful. I love drawing them on
> the
> board, and theorizing a ton of them out. But what about the device? To
> repeat:
>
> - Data: Information used to actually forward packets.
> - Control: protocols and processes used to build the information needed by
> the data plane.
> - Management: protocols, configuration, and processes that manage the
> device
> on which the control and data plane processes run, and configure/manage the
> control plane processes themselves.
>
> Seems pretty simple to me --it's not about speed (which can change), and
> it's not about remote/local, etc. I don't think it's perfect, but again, if
> we allow platypuses to define our model, we'll have a hard time with ducks
> and beavers.
>
> :-)
>
> Russ
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 7 Nov 2013 07:09:41 +0100
> From: Robert Raszuk <[email-masked]>
> To: Russ White <[email-masked]>
> Cc: Kireeti Kompella <[email-masked]>, SDN IRTF list
>         <[email-masked]>
> Subject: Re: [Sdn] Thoughts on Defining control and Management Planes
> Message-ID:
>         <
> [email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Russ,
>
> Brilliant ! So what *SDN* "real physical device" do you have in mind ?
>
> URL would be great as well as pointer to its specification !
>
> Maybe indeed we need to start from that, but I am afraid the
> discussion is going to be rather short ;-)
>
> Cheers,
> R.
>
> On Thu, Nov 7, 2013 at 6:59 AM, Russ White <[email-masked]> wrote:
> >
> >> The difficulty for some folks (like me) is to drag our heads out of
> > distributing
> >> everything on principle, and understand when centralization is a must.
> >
> > Of course --but that doesn't really help us determine a solid model to
> > use... The point here is to find a model that can be used to accurately
> > describe interactions and protocols at the device level, so we can sort
> and
> > classify the APIs and protocols needed at this level, then figure out how
> > those protocols and APIs relate to services and the network as a whole.
> >
> > I agree there is a need for higher level models to show how services
> > interact, and how the network works as a whole, but we can't simply
> ignore
> > that there are physical devices someplace connected to tangible wires
> that
> > must switch real packets between two specific destinations in the
> network.
> > If we can't describe what the pieces of that device are and how things
> > outside that device interact with it, then all the services and network
> > models in the world aren't going to get us from an architecture to
> actually
> > making packets flow from point a to point b. One of the problems with the
> > SDN space is we always start with the ocean and a thousand uncoordinated
> > matches. Let's try with a single small cup and a large stove instead.
> >
> > So the services and network models are beautiful. I love drawing them on
> the
> > board, and theorizing a ton of them out. But what about the device? To
> > repeat:
> >
> > - Data: Information used to actually forward packets.
> > - Control: protocols and processes used to build the information needed
> by
> > the data plane.
> > - Management: protocols, configuration, and processes that manage the
> device
> > on which the control and data plane processes run, and configure/manage
> the
> > control plane processes themselves.
> >
> > Seems pretty simple to me --it's not about speed (which can change), and
> > it's not about remote/local, etc. I don't think it's perfect, but again,
> if
> > we allow platypuses to define our model, we'll have a hard time with
> ducks
> > and beavers.
> >
> > :-)
> >
> > Russ
> >
> >
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 7 Nov 2013 01:27:18 -0500
> From: "Russ White" <[email-masked]>
> To: "'Robert Raszuk'" <[email-masked]>
> Cc: 'Kireeti Kompella' <[email-masked]>,    'SDN IRTF list'
>         <[email-masked]>
> Subject: Re: [Sdn] Thoughts on Defining control and Management Planes
> Message-ID: <[email-masked]>
> Content-Type: text/plain;       charset="us-ascii"
>
>
> > Brilliant ! So what *SDN* "real physical device" do you have in mind ?
>
> Do you need an actual unicorn to describe what a unicorn should look like?
> :-) Being a research group, it's okay to attempt to describe things that
> might not exist in the real world (I hope). It might even be a useful
> exercise (if it can give us a channel for energy, so we don't keep building
> horses with horns all over the place in an attempt to finally get to a
> unicorn...) I'm hoping it's worth a try, at any rate.
>
> :-)
>
> Russ
>
> P.S. OTOH, I could ask for some pointers to an operational "services based
> network," that doesn't have any hardware to switch actual packets. :-)
>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 7 Nov 2013 07:43:14 +0100
> From: Robert Raszuk <[email-masked]>
> To: Russ White <[email-masked]>
> Cc: Kireeti Kompella <[email-masked]>, SDN IRTF list
>         <[email-masked]>
> Subject: Re: [Sdn] Thoughts on Defining control and Management Planes
> Message-ID:
>         <
> [email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Is purpose of this IRTF group to describe new imaginary model of
> non-existent physical device used for undefined set of services ?
>
> Don't we have enough of those "research" already elsewhere ?
>
> > P.S. OTOH, I could ask for some pointers to an operational "services
> > based network," that doesn't have any hardware to switch actual
> > packets. :-)
>
> That's simple .. all *overlay* services work equally well over any
> transport .. physical or virtual. But this was not the point.
>
> The point was to suggest focusing on SDN as service driven research to
> be able to map it later to any forwarding transport paradigm. That
> IMHO could be the most useful approach for applied research as opposed
> to spending time on theoretical/imaginary neverending discussions.
>
>
> ------------------------------
>
> Message: 7
> Date: Thu, 7 Nov 2013 09:27:10 +0100
> From: Pedro Martinez-Julia <[email-masked]>
> To: [email-masked]
> Subject: Re: [Sdn] Thoughts on Defining control and Management Planes
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=utf-8
>
> On Thu, Nov 07, 2013 at 03:42:01AM +0000, Yaakov Stein wrote:
> > What SDN has done is not so much separating the user plane from the
> control plane -
> > that was well known (and as aforementioned this misses the management
> plane).
> > What SDN does is remove the control plane and rename the centralized
> management plane to be "control" instead.
> > It does so at the expense of emphasizing consistency, but losing the
> ability to simultaneously guarantee availability and partition tolerance.
> >
>
> Really? I don't think so. Maybe I am misunderstanding the SDN concept
> but, from my point of view, SDN provides enormous flexibility to the
> scene, so different networks can have different levels of control and
> management functions, either centralized or decentralized. With SDN you
> can still decide to keep the control model tightly coupled with the
> forwarding model, i.e. having a controller per switch/router, or you can
> decide the opposite, have just one centralized controller in charge of
> the control and to which you interact to achieve management. It is up to
> the network architect to determine the requirements of the network and
> translate them to a specific model. SDN enables you to do it.
>
> >
> > Y(J)S
> >
>
> Regards,
> Pedro
>
> --
> Pedro Martinez-Julia
> Department of Communication and Information Engineering
> Faculty of Computer Science
> University of Murcia
> Email: [email-masked]
> ---------------------------------------------------------
> *** Entia non sunt multiplicanda praeter necessitatem ***
>
>
> ------------------------------
>
> _______________________________________________
> sdn mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/sdn
>
>
> End of sdn Digest, Vol 19, Issue 8
> **********************************
>

---

From: Russ White <[email-masked]>
Date: Mon, 11 Nov 2013 18:54:33 -0500

Then routed ip networks don't have a management plane... But this is another problem with classifying these planes by there characteristics rather than their function.

What functional difference does it make how the packet gets there?

:-)

Russ

-----Original Message-----
From: "Yaakov Stein" <[email-masked]>
Sent: ‎11/‎11/‎2013 12:43 PM
To: "Russ White" <[email-masked]>; "'Robert Raszuk'" <[email-masked]>; "'Pedro Martinez-Julia'" <[email-masked]>
Cc: "'SDN IRTF list'" <[email-masked]>
Subject: RE: [Sdn] Thoughts on Defining control and Management Planes

No, BFD is data plane.

Control plane protocols can be sent out-of-band;
would out-of-band BFD mean anything ?

Y(J)S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Russ White
Sent: 11 November, 2013 16:31
To: 'Robert Raszuk'; 'Pedro Martinez-Julia'
Cc: 'SDN IRTF list'
Subject: Re: [Sdn] Thoughts on Defining control and Management Planes

> How would you classify BFD running between two devices ? To which 
> plane in your "very clear" model does it belong ?

The control plane --it is a protocol which impacts the information used to actually forward packets. Speed doesn't matter, function does.

:-)

Russ

---

From: Russ White <[email-masked]>
Date: Mon, 11 Nov 2013 18:57:18 -0500

Function, not characteristics. If we consider control plane protocols "data plane," because they carry control days (but its still data), then everything is data plane, no matter the speed, or function, or in band, or out of band, etc.

Function, not characteristic.

:-)

Russ

-----Original Message-----
From: "Robert Raszuk" <[email-masked]>
Sent: ‎11/‎11/‎2013 1:53 PM
To: "Yaakov Stein" <[email-masked]>
Cc: "Russ White" <[email-masked]>; "SDN IRTF list" <[email-masked]>; "Pedro Martinez-Julia" <[email-masked]>
Subject: Re: [Sdn] Thoughts on Defining control and Management Planes

Indeed - I am with Yaakov here - for me BFD is also much closer to
data plane then any other plane. It can run in hardware on a line
cards too never even touching local or remote RP/RE where control
plane resides.

Likewise an interesting question could be to asked about soft-state
RSVP-TE ... most will say ohhh for sure control plane .. but TE-LSP is
effectively a link and link or node is really a transport for packets.

So data plane is not just programming routes or flow-mods to FIB. It
is also hardware as well as software which builds data plane.

Same for software on the line cards .. for example FIB construction
there it has really nothing to do with control plane at all.

---

Actually I am not sure why we need this "plane" classification.
"planes" can be drawn where we have full system - again starting from
what do you want to accomplish - what service(es) you are to run.
Arguing for definition of planes now seems to me pretty pointless :-)

r.

---

From: Russ White <[email-masked]>
Date: Mon, 11 Nov 2013 19:00:31 -0500

It'd not about dividing complexity, its about dividing function. Does it carry transit traffic offered to the network by something other than aneywork device? Then its either control or management, not data. 

Maybe attaching qualifiers to the name would help.

User data
Data plane control
Network management 

Does that gel?

:-)

Russ

-----Original Message-----
From: "Robert Raszuk" <[email-masked]>
Sent: ‎11/‎11/‎2013 2:18 PM
To: "Pedro Martinez-Julia" <[email-masked]>
Cc: "SDN IRTF list" <[email-masked]>
Subject: Re: [Sdn] Thoughts on Defining control and Management Planes

Hi Pedro,

> I think you are attributing so much to data plane. Data plane should
> just have functions that do not analyze the content of packets, i.e.
> functions that just decide to forward (or not) a packet and to which
> port it should be forwarded.

I think you on the other hand vastly underestimate it.

Decision on where to forward the packet, how to decapsulate and
encapsulate it, decision about ECMP forwarding using physical and
virtual links, building FIB hierarchy all require sometimes complex
and time optimized code as well as do need deep analysis of the
content of the packet.

What you sort of describe is of 1.0 definition ... and that's why its
of little use for practical applications.

Best,
R.

---

From: Russ White <[email-masked]>
Date: Mon, 11 Nov 2013 19:04:20 -0500

Not necessarily. It's a protocol that notifies a client, and that client can be a routing protocol that would modify forwarding, or the client can be a notification to an NMS that will log it without impact to forwarding. The client can event be just a stub with no "action". Maybe BFD is plane-less :-)
==

It notifies a client which then modifies the forwarding information... If we include everything that might eventually touch the forwarding information, then everything us data plane, including CPU thermals (since the CPU night overheat, causing the box to shut down, which has a definite impact on the data plane).

If you do this, you have no interfaces, and interfaces are where the definition needs to be clear.

:-)

Russ

-----Original Message-----
From: "Carlos Pignataro (cpignata)" <[email-masked]>
Sent: ‎11/‎11/‎2013 4:52 PM
To: "Russ White" <[email-masked]>
Cc: "Robert Raszuk" <[email-masked]>; "Pedro Martinez-Julia" <[email-masked]>; "SDN IRTF list" <[email-masked]>
Subject: Re: [Sdn] Thoughts on Defining control and Management Planes

On Nov 11, 2013, at 9:30 AM, Russ White <[email-masked]> wrote:

> 
>> How would you classify BFD running between two devices ? To which plane
>> in your "very clear" model does it belong ?
> 
> The control plane --it is a protocol which impacts the information used to
> actually forward packets.

Not necessarily. It's a protocol that notifies a client, and that client can be a routing protocol that would modify forwarding, or the client can be a notification to an NMS that will log it without impact to forwarding. The client can event be just a stub with no "action". Maybe BFD is plane-less :-)

Seems like BFD is executing a fault management function, triggering control planes and management planes. I am not sure this makes a huge difference in any case :-)

> Speed doesn't matter, function does.
> 

That I agree with.

-- Carlos.

---

From: Russ White <[email-masked]>
Date: Wed, 13 Nov 2013 12:45:54 -0600

If the definitions change over time, then we can't build stable interfaces and their associated data models, nor can we understand how to compare one network or service model against another....

So... I'd argue for a functional model (what it does), that is going to be stable over time... Not time, service, or "who did this," or...

:-)

Russ

-----Original Message-----
From: "Alan Clark" <[email-masked]>
Sent: ‎11/‎13/‎2013 12:13 PM
To: "[email-masked]" <[email-masked]>
Subject: Re: [Sdn] Thoughts on Defining control and Management Planes

How about a definition along the following lines?

The functionality of a switching or routing system is typically divided into three layers, Data Plane, Control Plane and Management Plane. As network architectures evolve, the functions incorporated into these planes may change; for example adaptive algorithms incorporated into the Control Plane may automate configuration or optimization tasks that would historically be performed by the Management Plane.

The Data Plane is distributed throughout the network and exists within each network node. The Data Plane provides switch, routing, transformation and filtering functions such as packet forwarding, encapsulation and address translation.  These functions and the associated interfaces are configured by the Control Plane. 

The Control Plane may be distributed or centralized and is primarily responsible for configuration of the Data Plane. Typical Control Plane functions include maintaining knowledge of the local or global topology and current loading of the network, calculating optimal routes through the network based on policy and with minimal cost, instantiating the route by configuring the Data Plane in the nodes traversed by the route and maintaining data on the routes currently configured in the network. Control plane functions may also include failure handling mechanisms such as link failure detection and fail over, and automated provisioning of devices from a server.  A Control Plane typically incorporates some detection and reporting of faults and exceptions, and this data is reported to (or retrieved by) the Management Plane. If the Control Plane was disconnected from the Data Plane then the current configuration of the Data Plane would remain unchanged (i.e. no new routes would be set up, no new devices would be provisioned...) and data could still be forwarded according to that configuration.

The Management Plane is typically centralized and is primarily responsible for ensuring that the network or system is running optimally when viewed from an overall service and business perspective. The Management Plane will effect this by gathering data from the network on usage, performance and faults, determining either manually or automatically if changes to the configuration of the Control Plane would improve overall performance, resource utilization, security and reliability of the network and those services or applications running over it and making changes to Control Plane configuration if needed, converting collected data into accounting information for billing or operational cost models, and overriding the normal operation of the Control Plane to handle exception conditions.  A Management Plane always includes some element of reporting faults and exceptions to human operators. If the Management Plane was disconnected from the Control Plane, the network would continue to operate normally however issues or traffic pattern changes that affect the performance and reliability of the network may not be detected and the network may operate sub-optimally.

As a non-network example - the set of traffic lights at a junction have a local control function (Control Plane element) that applies a configured set of rules to decide when to change lights based on time and road sensors. This may be locally optimal in terms of minimum queuing delay at a junction however may not be globally optimal. A Management Plane would have visibility over the entire road system and could make adjustments to the rules used by each local control function in order to achieve global optimization. If at some future time the local control functions become integrated into a system-wide Control Plane and this is able to use system-wide data to optimize traffic light operation across the network then it has become a more intelligent Control Plane and the Management Plane's role evolves to one of controlling the configuration of the system-wide optimization algorithm. 

Regards

Alan

On 11/13/13, 9:33 AM, Scott Brim wrote:

On Tue, Nov 12, 2013 at 8:31 AM, Russ White <[email-masked]> wrote:

>       > For me the difference is between something that is supposed to be
> in continuous operation, and something that is supposed to set up that
> continuous operation.  I see the former as control plane and forwarding
> plane, and the latter as management.  When you perform a management
> function, then you can sit back and watch to make sure you did it right.
A
> control function, on the other hand, continues _as part of_ things going
right.
>
>       I think this merges the control and data planes, though -- and I
think
> we want to be able to differentiate between them.
>
> Russ, maybe it merges your concepts of planes, but I'm trying to get you
to
> use different concepts. In what I said, control and management are clearly
> separated. We can get to specifics if you like, as tests of conceptual
models.
> Just keep in mind that components function in multiple planes
> simultaneously.

Given your definition --these things are all in continuous operation, 

That's not what I meant to say, and sorry for using those words. Trying again: management sets up and monitors the network machinery, while control operates it. I'll give up on getting succinct sound bytes soon.
 
so
they must all be control plane:

You know that's impossible.
 
- Forwarding of packets

Forwarding. 

(One nit is that forwarding of control or management plane packets has generally not been considered "forwarding plane" -- it's special in the abstract, even though in IP networks transport of control/mgmt is actually done using the same IP forwarding mechanisms.)

- Detection of down links

Categorizing that, and others below, depends on the function that receives the result. What does it do? If it changes configuration, it's management. If it changes behavior for now but does not change configuration, it's control.
 
- Flooding and maintenance of topology information

Control
 
- Monitoring of cpu thermals 
- Monitoring of memory utilization

Again, it depends on how the information will be responded to.  The information isn't the point, it's whether it's used for management or control.
 
- Logging

Management.
 
- Reactive configuration to black hole attacks

Good one. I would call this a rapid response of management.

The last time I tried to define planes was in Y.2011.  Here, I originally thought the goal was to have consistency with other definitions of "planes", but it looks like these definitions are just going to be used in SDNRG (they already disagree with at least one other SDN group). If all this is local scope, whatever you all decide on is fine. I look forward to a draft.

Scott