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

From: Russ White <[email-masked]>
Date: Wed, 6 Nov 2013 09:58:56 -0800

Y'all:

In the SDN meeting, there was some discussion over the management and control planes. I think defining these two is important in having consistent language (hermeneutics being a hobby of mine, among many others). To wit, a possible set of definitions for consideration and discussion. Not claiming these are perfect, but I do think we need to get past "this is faster than that," and other permeable boundaries.

- control plane: Those processes / configuration which directly impacts the information used to forward (or switch) traffic through a device. This would include distributed protocols, static configuration, etc.

- management plane: Those processes or configuration that modify the operation of the control plane, or the general operation of the device on which the control plane processes run.

- data plane: The information and processes actually used to forward or process packets.

So, for example:

- OSPF is a control plane protocol
- Configuring which interfaces OSPF runs on is a management function, since it impacts the operation of a control plane protocol
- FORCES is a control plane protocol ( in the main)

A single SDN system might interact with all three, of course (though I tend to believe these are different enough areas to warrant different solutions).

I know there are probably hard cases that won't cleanly fit here, but we shouldn't let platypuses disturb our ability to differentiate between a duck and a beaver... Thoughts and discussion welcome, just would like to get this nailed down so we can actually have a common language to work from.

:-)

Russ

<><
[email-masked]
Ericsson

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 6 Nov 2013 18:11:57 +0000

It would be more useful to clarify why the NETCONF, that is commonly perceived as interface to management system, can't be used as interface to Controller. I've heard that NETCONF can't do it fast enough.
What is the minimum speed for interface to Controller?

Linda
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Russ White
> Sent: Wednesday, November 06, 2013 11:59 AM
> To: [email-masked]
> Subject: [Sdn] Thoughts on Defining control and Management Planes
> 
> Y'all:
> 
> In the SDN meeting, there was some discussion over the management and
> control planes. I think defining these two is important in having
> consistent language (hermeneutics being a hobby of mine, among many
> others). To wit, a possible set of definitions for consideration and
> discussion. Not claiming these are perfect, but I do think we need to
> get past "this is faster than that," and other permeable boundaries.
> 
> - control plane: Those processes / configuration which directly impacts
> the information used to forward (or switch) traffic through a device.
> This would include distributed protocols, static configuration, etc.
> 
> - management plane: Those processes or configuration that modify the
> operation of the control plane, or the general operation of the device
> on which the control plane processes run.
> 
> - Configuring which interfaces OSPF runs on is a management function,
> since it impacts the operation of a control plane protocol
> A single SDN system might interact with all three, of course (though I
> tend to believe these are different enough areas to warrant different
> solutions).
> 
> I know there are probably hard cases that won't cleanly fit here, but
> we shouldn't let platypuses disturb our ability to differentiate
> between a duck and a beaver... Thoughts and discussion welcome, just
> would like to get this nailed down so we can actually have a common
> language to work from.
> 
> :-)
> 
> Russ
> 
> 
> 
> <><
> [email-masked]
> Ericsson
> _______________________________________________
> sdn mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/sdn

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 6 Nov 2013 19:27:13 +0100

Hi Russ,

To me network consists of three fundamental functional blocks:

-A- topology discovery (centralized or distributed)
-B- reachability computation/distribution/installation
-C- monitoring/configuration

Using your control plane vs management plane I see only the last one
-C- can be categorized quite clearly as the mgmt plane.

For -A- and -B- I have see real examples of complete mixture and any
attempt to put those in any of your basket will clearly fail.

Best,
R.

---

From: Pedro Martinez-Julia <[email-masked]>
Date: Wed, 6 Nov 2013 19:31:39 +0100

> What is the minimum speed for interface to Controller?

NETCONF is either a control and management protocol, depending on the
function that it is used to do.

> Linda

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 ***

---

From: Russ White <[email-masked]>
Date: Wed, 6 Nov 2013 10:33:33 -0800

The first part of the question is, then, should we take a network centric view of the question, or a device centric view. IMHO, as much as I think the network as a whole is crucial, the only way actually move forward with workable definitions is with a device centric view (from which we build broader network level models). You've essentially subsumed my entire model in one category within your model -- but I'm afraid that If we start with the ocean, streams and rivers become indistinguishable.

:-)

Russ

<><
[email-masked]
Ericsson

> On Nov 6, 2013, at 10:27 AM, Robert Raszuk <[email-masked]> wrote:
> 
> Hi Russ,
>

---

From: Russ White <[email-masked]>
Date: Wed, 6 Nov 2013 10:35:49 -0800

I'd prefer to start with understanding what the areas are, then build requirements for those areas, then decide why protocol x will or won't work. This is actually why I don't think we can start with, "faster is control plane, slower is management," won't work, because it subsumed requirements within the definition itself.

:-)

Russ

<><
[email-masked]
Ericsson

> On Nov 6, 2013, at 10:11 AM, Linda Dunbar <[email-masked]> wrote:
>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 6 Nov 2013 19:43:45 +0100

Russ,

IMHO we should take neither. Neither network nor device model works.

SDN is about service models and then it can be mapped to network to
realize it. of course networks consists of devices (physical or
virtual).

Such mapping can be done via some controller automation (example SDN compiler).

So finding what service is the target (can be multiple) is like first
knowing where do you want to go on a map, before specifying your turn
by turn directions.

And of course there will be different set of directions depending what
"network" types you are traversing ... city, forest, sea, air will all
have very different results.

Best,
R.

---

From: Pedro Martinez-Julia <[email-masked]>
Date: Wed, 6 Nov 2013 19:44:18 +0100

> -A- topology discovery (centralized or distributed)

In the context of current networks and SDN, I think that topology
discovery should not be into the "core" functional blocks. I do not
doubt that knowing the status of a device or link is important bu I
advocate for separating "topology discovery", which should not be
required for all scenarios, and "status control", which would be
required by (almost) all scenarios.

> -B- reachability computation/distribution/installation

I agree on this and those could be certainly classified as control plane
functions.

> -C- monitoring/configuration

As you mentioned, this is a typical management plane function.

Regards,
Pedro

---

From: Pedro Martinez-Julia <[email-masked]>
Date: Wed, 6 Nov 2013 19:51:28 +0100

> I'd prefer to start with understanding what the areas are, then build requirements for those areas, then decide why protocol x will or won't work. This is actually why I don't think we can start wi…

By the way, do we have something like a wiki page where we can edit together to reach an agreement on the definitions. It is very important to have the concepts very clear before discussing more deep questions.

Regards,
Pedro

---

From: Russ White <[email-masked]>
Date: Wed, 6 Nov 2013 10:52:59 -0800

The service model cuts across the network and device divide, but I think describing individual devices can fit within the service model, or rather that a device centric model can be used to help build a service oriented model in the long run. But starting from a services model won't help us (I don't think) to build and understand the device level models needed to talk intelligently about the problems that need to be addressed.

:-)

Russ

<><
[email-masked]
Ericsson

> On Nov 6, 2013, at 10:43 AM, Robert Raszuk <[email-masked]> wrote:
> 
> Russ,
>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 6 Nov 2013 20:02:47 +0100

> required by (almost) all scenarios.

I think topology discovery is extremely important for any service
delivery (including overlays).

In fact I think that's a mistake of number of SDN folks including ONF
where they do not focus on topology. That alone allows one to say that
IGPs are legacy yet they do not provide any where equal connectivity
restoration mechanisms.

Thx,
r,

---

From: Pedro Martinez-Julia <[email-masked]>
Date: Wed, 6 Nov 2013 20:23:26 +0100

> delivery (including overlays).

It may be if the interested party do not know the topology but the SDN
controllers *must* know the topology of their network, so the only
missing function would be to control its state. I am not arguing against
having a topology discovery function as part of the network but I think
it should be separated from the state of elements and links.

> IGPs are legacy yet they do not provide any where equal connectivity

As the controllers are in responsible of topology and link states, IGPs
following the current model are no longer needed. However some functions
may require an IGP-like protocol for controller-to-controller exchange
of status (and topology) information.

Regards,
Pedro

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 6 Nov 2013 20:31:23 +0100

Ahhh ok I was mainly talking about state of links and nodes.

Physical topology discovery/verification is also needed though.

Regarding your comment that igp-s are no longer needed we clearly have
different opinions and can agree to disagree here ;).

Best,
R

---

From: "Russ White" <[email-masked]>
Date: Wed, 6 Nov 2013 16:32:35 -0500

> different opinions and can agree to disagree here ;).

A world without IGPs would be like a world without... Well... Sliced bread?
I don't know. Scary thought.

:-)

Russ

---

From: "Russ White" <[email-masked]>
Date: Wed, 6 Nov 2013 16:35:19 -0500

> I am trying to understand whether your definition of management plane also
> includes a view of resources on devices. After all, if one does not know
what
> devices are in one's network, how do we manage them? This might be in
> "discovery" operation for topology but manageability is not limited to
> topology only. I am talking about configurable parameters on devices that
> only a management plane would deal with such as queues, TCAM spaces (or
> flow spaces), etc.

I would consider resources, such as memory, physical ports, cpu, power,
environmentals, etc., all within the management plane, myself. Of course I'm
open to having my mind changed (the point of discussion!) through some other
model... It might also be useful to somehow differentiate between management
of the protocols in the control plane, and management of the device on which
the protocols run in some way (?).

:-)

Russ

---

From: Pedro Martinez-Julia <[email-masked]>
Date: Wed, 6 Nov 2013 22:42:34 +0100

> I don't know. Scary thought.

I prefer to see a world where each "entity" is dedicated and specialized
to do its job, and dealing with IGP is not a good job for a forwarding
entity. The more functionality you include into the forwarding entity,
the less efficient it is.

Regards,
Pedro

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 6 Nov 2013 14:52:34 -0800

The issue is that you perhaps do consider the complexity associated with distribution from controller to network element required for forwarding data.

All I can say that number of existing distributed routers do struggle a lot to distribute forwarding state from local RE/RP to local line cards. Most do it via fabric replication or local reliable multicast. Doing the same over network may work on slides or on lab with 5 routes but I am extremely pessimistic that you can do this over network at any decent scale.

The you need to consider protection computation like LFAs which for each node and each link will be different. It just does not make sense to centralize everything.

You centralize what you must and distribute what you can.

Best,
R.

Sent from my iPad

> On Nov 6, 2013, at 1:42 PM, Pedro Martinez-Julia <[email-masked]> wrote:
>

---

From: Yaakov Stein <[email-masked]>
Date: Thu, 7 Nov 2013 03:42:01 +0000

I would like to explain my comment at the meeting on the difference between the two planes,
and add something about why the difference between the two is important.

In the olden days, three planes were defined - the data or user (or forwarding) plane,
the control plane, and the management plane.
The difference between the latter two was less functional than operational.

The control plane was fast and distributed and local.
The management plane was anything that required, or at least enabled, human intervention.
As an example, OAM messages are user plane (since they fate share with user data), but may trigger control protocol operations such as protection switching,
or may trigger alarms (management plane) or be used to collect statistics that can be retrieved via the management plane.

Over time more and more "intelligent" operations that were once performed by humans
were replaced by software. However, two fundamental differences remained.
First - since control plane operations are automatic they remain faster than management plane operations. 
Second - since humans were localized in NOCs the management intelligence remains centralized,
while control protocols are distributed.

Why did these two planes not fuse ? 
Because there are operations that are better carried out locally, 
and there are others that are better managed from a central management site.

The reason has to do with the CAP theorem.
I don't have the room to fully explain this here,
but the CAP theorem dictates that at most two of consistency, availability, and partition tolerance can be achieved simultaneously.
Here the calculation to be carried out is how to forward packets from ingress to egress.
In general, service providers are required to guarantee availability (e.g., five nines)
and partition tolerance (e.g., 50 msec) for operational services,
and they forgo consistency (which is why we need OAM and TTL fields). 
This can be carried out by distributed local control planes, but not by centralized management systems.
However, there are tasks that require consistency and can give up availability,
such as new service creation; these require a centralized management system
(which is why service activation is slow - it is not immediately available).
Network operations involves disciplined decision behind the use of one or the other plane
for various tasks.

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.

Y(J)S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Russ White
Sent: 06 November, 2013 19:59
To: [email-masked]
Subject: [Sdn] Thoughts on Defining control and Management Planes

Y'all:

So, for example:

:-)

Russ

<><
[email-masked]
Ericsson

---

From: Kireeti Kompella <[email-masked]>
Date: Wed, 6 Nov 2013 20:09:12 -0800

Right on!

---

From: Kireeti Kompella <[email-masked]>
Date: Wed, 6 Nov 2013 20:13:13 -0800

> 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.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 7 Nov 2013 06:36:03 +0100

Hi Kireeti,

> 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.

---

From: "Russ White" <[email-masked]>
Date: Thu, 7 Nov 2013 00:59:37 -0500

> 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

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 7 Nov 2013 07:09:41 +0100

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.

---

From: "Russ White" <[email-masked]>
Date: Thu, 7 Nov 2013 01:27:18 -0500

> 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. :-)

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 7 Nov 2013 07:43:14 +0100

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.

---

From: Pedro Martinez-Julia <[email-masked]>
Date: Thu, 7 Nov 2013 09:27:10 +0100

> 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.

Regards,
Pedro

---

From: Pedro Martinez-Julia <[email-masked]>
Date: Thu, 7 Nov 2013 10:38:52 +0100

> control plane processes themselves.

Be careful with these definitions because they imply a single device for
the control and data planes.

More precise definitions are needed. For instance, the data plane
definition should remark that its only function is to forward data
packets without looking to their payload unless they are targeted at the
device that forwards them.

It could be difficult to have a single definition of the planes but I
think that almost everybody agree in that there are three separate
planes and also agree in the spirit behind this separation. We should
begin at this point to build some consistent and agreed definitions of
the planes.

Something like a wiki page to gather different definitions and work on
them to refine a potential single definition could be good to reach a
good level of agreement.

Regards,
Pedro

---

From: "Russ White" <[email-masked]>
Date: Thu, 7 Nov 2013 08:48:57 -0500

> > - 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.
> >
> 
the
> control and data planes.

Two points:

- They're designed to represent a single device. I'm trying to represent a
single device intentionally for a specific reason (see below).

- The way you get to groups of devices is by combining groups of actual
devices. I understand the need for models that capture the behavior of
groups of devices, as well, but I don't understand how such models can be
useful when actually interacting with single devices. In other words, if you
have a model for a network, that's all fine and dandy, but that model has to
eventually interact with the actual single devices that make up the
"network" at some point. Hand waving and saying, "we don't care about single
devices," won't work -- somehow the information required to switch actual
packets must be sent to and managed on actual physical individual devices.

> More precise definitions are needed. For instance, the data plane
definition
> should remark that its only function is to forward data packets without
> looking to their payload unless they are targeted at the device that
forwards
> them.

This isn't more precise, it is g --it is jumping to the network model.
There's nothing wrong with network models --we need such things-- but now
you have this generalized data plane containing all the information across
ten thousand devices. Great. How do you actually install the data plane
information on each of those ten thousand devices? What is the protocol?
What is the model? OTOH, vendors and people who manage these networks also
need to know how the individual device they're building, or that's sitting
in front of their face in a rack in the real world, interact with that
network model. 

I could, for instance, say, "OSPF's control plane is the shared database
across all the devices in a flooding domain," and I'd be right. But that
doesn't tell me anything about how that database was shared, or how it's
used, or how consistency is (roughly) enforced, or how mismatches between
the topology and the database are detected, etc. Those things are all at the
individual device level, and would need to be modeled as interactions
between individual devices. Both models are useful, and both are also
necessary.

> It could be difficult to have a single definition of the planes but I
think that
> almost everybody agree in that there are three separate planes and also
> agree in the spirit behind this separation. We should begin at this point
to
> build some consistent and agreed definitions of the planes.

That's the problem with network level models --there are too many
definitions, and they vary according to the application and protocols in
place. Part of the reason we're spinning around without a lot of progress in
actually researching is that when you work from the network model, the only
option you have is to say, "well, we did this using this model," and "we did
that using that model." 

IMHO, one way forward is to impose a model for an individual device so we at
least start with that one thing in common, and then let's see where we can
go from there. I'm not positing that we limit ourselves to a single device
model, only that we start there, because I think we can actually get to a
single device model everyone can agree on if we think about it hard enough.
Once we get that piece in place, we have common ground to start talking
about network and service models in relation to the single device model we
all share. 

:-)

Russ

---

From: "Russ White" <[email-masked]>
Date: Thu, 7 Nov 2013 09:07:40 -0500

> Is purpose of this IRTF group to describe new imaginary model of non-
> existent physical device used for undefined set of services ?

I thought the purpose was to research into the purpose and applications of
SDNs, to help guide the work of various IETF working groups working in this
space. IMHO, one of the fundamental things we can do here is to build the
models and definitions needed to have common ground so we can talk about
such things. Saying, "here is a limitless number of service models to work
from, choose according to your need," isn't particularly useful unless you
have some way to actually instantiate some of those models on individual
devices. :-)

Let me point something out that might not be so obvious, but I think is
fairly interesting. We have at least four widely deployed IGPs in the wild,
and one widely deployed EGP. All of them share the same model of a single
device, and work from that same model when defining the protocols and
network models from which they work. I don't think this was a conscious
decision, but rather a matter of the interaction of the hardware and
software. This "single device model," isn't the only model in play, but it
sets a baseline which is useful to all the protocols, and helps everyone
have discussions around how those protocols work, etc.

> That's simple .. all *overlay* services work equally well over any
transport ..

Overlay networks are called "overlay networks," because they overlay some
actual physical network which presumably has physical devices forwarding
individual packets. At least I don't know of any overlay network that has
become so abstract that it doesn't have to run on physical hardware
someplace or another in the final analysis... I guess white board
demonstrations might count, but I'm not certain how many folks will pay for
a white board network, rather than a real world one.

> 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.

My point is that focusing on service models will lead us to a never ending
spin on the different service models available, and we won't be able to map
any of it to any sort of transport because we won't have a single model onto
which to map all these services (or rather to instantiate them). If we start
from the other end, then we actually have a common model where, when someone
presents a new service model, we can say, "how does this map onto actual
physical devices that forward real packets?" It provides a ground from which
to work.

Castles in the air are great, but you either need to ground them (turning
them into fog, like all good cloud designs), or you can just watch while
they blow away, to be replaced by another beautiful cloud in ten minutes.

:-)

Russ

---

From: Pedro Martinez-Julia <[email-masked]>
Date: Thu, 7 Nov 2013 17:10:51 +0100

> about network and service models in relation to the single device model we

I agree with this. We have to specify the basement to define such device
model. I propose to begin here with a draft definition of the functions
that should be supported by a single device and the interfaces it offers
to other devices or elements.

According to this I like the "keep it simple" principle so I would start
with a simple device model:
- N ports for incoming/outgoing packets.
- A forwarding table with rules used to determine the outgoing port for
  the packets that match them.
- A packet analyzer that matches incoming packets (from incoming ports)
  with the rules of the forwarding table.
- At least two queues (incoming/outgoing) for each port.
- A status control unit that verifies each hardware component to know
  its working status and other performance values. This includes:
  + A link status monitor that verifies that a link works and that the
    device/element connected to the other side is working correctly.
  + A queue checker that verifies that a queue is not dropping packets
    constantly.
- A configuration unit that stores the different options supported by
  the device and sets them to the units that correspond to them.
- A control interface that can be used by other elements to query and/or
  update the entries of the forwarding table.
- A management interface that can be used by other elements to get the
  status collected by the status control unit and to configure different
  variables of the device.

This model is a very initial draft so it is incomplete (and superfluous)
but, please, let me know your thoughts or opinions. Thank you.

Regards,
Pedro

---

From: "Russ White" <[email-masked]>
Date: Thu, 7 Nov 2013 11:35:27 -0500

> - At least two queues (incoming/outgoing) for each port.

These would all fit as components under the data plane in the model I
proposed previously.

>   status collected by the status control unit and to configure different

These would all fit under the management plane in the model I previously
proposed. 

There would be a third component, the control plane, which is the
intermediary between protocols and processes that maintain a view of the
network state and the actual data plane databases.

On the whole, I'd like to work from the middle --we can work down to
components, and up to network, but we need three or four broad categories
which will serve to describe all the "stuff" that goes on in a single
device. These things need to be abstract enough to be useful from above, and
yet specific enough to be useful from below.

:-)

Russ

---

From: David Meyer <[email-masked]>
Date: Thu, 7 Nov 2013 08:37:44 -0800

Yaakov,

> and add something about why the difference between the two is important.

First, thank you for your thoughtful analysis.

> while control protocols are distributed.

Agreed, this is history. But as I mentioned this paradigm (almost
explicitly) no longer really applies (especially in the age of what I
would call "deep automation"; see e.g. [0]; but then I think we all
know this).

> but the CAP theorem dictates that at most two of consistency, availability, and partition tolerance can be achieved simultaneously.

I highly advise [1] for folks seeking to get some intuition about what
the CAP theorem is  all about.

> This can be carried out by distributed local control planes, but not by centralized management systems.

Proponents of centralized approaches might disagree. Personally it
seems almost trivial to see that a lower bound would be something like

LB(convergence) = RTT(controller, switch) + PPT(controller) + PPT(switch)

where

RTT is the round trip time, and PPT is the packet processing time
(note in the case of something like OF you might have sum this over
the entire  path).

> (which is why service activation is slow - it is not immediately available).

I would s/require/can make use of/g

(require is a strong term that needs something to substantiate it).

> that was well known (and as aforementioned this misses the management plane).

Yes, nothing new under the sun. However, separation of control and
data planes was a key component of what was perhaps early thinking
about the attributes of what was then called SDN. See e.g., [2] (or
any number of other references). Now, if you are arguing that those
definitions were either wrong is fair game, however, that doesn't
change the fact that control/data plane separation was a key part of
early definitions of SDN.

> It does so at the expense of emphasizing consistency, but losing the ability to simultaneously guarantee availability and partition tolerance.

That is also not clear. I can make the "centralized management plane"
a distributed system as well, at which point the CAP theorem is in
play.

Thx,

--dmm

[0] http://www.theregister.co.uk/2013/11/04/google_living_omega_cloud/
[1] http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed
[2] https://www.opennetworking.org/sdn-resources/sdn-definition

---

From: David Meyer <[email-masked]>
Date: Thu, 7 Nov 2013 08:44:13 -0800

> a distributed system as well, at which point the CAP theorem is in

I see that I kinda misread your statement. My point is that since the
"centralized management plane" can be a distributed system (I would
ague "has to be" for reasons of scale and resilience), then CAP
tradeoffs are in play. We might have designed for the tradeoff that
you mention, but that is not "architecturally" required.

--dmm

---

From: David Meyer <[email-masked]>
Date: Thu, 7 Nov 2013 08:50:53 -0800

> translate them to a specific model. SDN enables you to do it.

I agree with you but the decomposition you mention doesn't seem to be
clean, namely, loose/tight coupling vs. number of control planes. In
particular,  I can have one controller/switch but still have them be
loosely coupled.

--dmm

---

From: "Gurkan, Deniz" <[email-masked]>
Date: Thu, 7 Nov 2013 11:45:15 -0600

We published a limited experience with management plane within OpenFlow-capable device-based network on GENI (http://www.geni.net) based on OFConfig (NetConf on transport).

Narisetty, RajaRevanth, Levent Dane, Anatoliy Malishevskiy, Deniz Gurkan, Stuart Bailey, Sandhya Narayan, and Shivaram Mysore. "OpenFlow Configuration Protocol: Implementation for the of Management Plane." In Research and Educational Experiment Workshop (GREE), 2013 Second GENI, pp. 66-67. IEEE, 2013.

I am trying to understand whether the definition of management plane also includes a view of resources on devices. After all, if one does not know what devices are in one's network, how do we manage them? This might be in "discovery" operation for topology but manageability is not limited to topology only. I am talking about configurable parameters on devices that only a management plane would be dealing with such as queues, TCAM spaces (and/or flow spaces), etc.

Deniz

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Russ White
Sent: Wednesday, November 06, 2013 11:59 AM
To: [email-masked]
Subject: [Sdn] Thoughts on Defining control and Management Planes

Y'all:

So, for example:

:-)

Russ

<><
[email-masked]
Ericsson

---

From: Pedro Martinez-Julia <[email-masked]>
Date: Thu, 7 Nov 2013 20:24:29 +0100

> particular,  I can have one controller/switch but still have them be

Yes, you can. That is part of the flexibility I am talking about. I was
mistakenly too much specific in the definition.

Regards,
Pedro

---

From: Sharon <[email-masked]>
Date: Sun, 10 Nov 2013 07:54:28 -0800

That's an excellent account of the problem statement...
the clear need for immediate, non topological, non stochastic network cloud-programming, And the CAP wall!

As far as am ware there will never be a silver bullet solution, defiantly not (only) seaming lack of partition using out of band centralized circuit-flow switching.

However there's a clear way to reduce the CAP for net-programming problem to CAP to databases using flow-overlays with shared fate underlay-mapping.  Not a full solution but excellent proven best practices.

Highly recommend taking a look at the solutions in this space, namely - lisp 4 nvo, lisp 4 nfv

--szb

On Nov 6, 2013, at 7:42 PM, Yaakov Stein <[email-masked]> wrote:

Y(J)S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Russ White
Sent: 06 November, 2013 19:59
To: [email-masked]
Subject: [Sdn] Thoughts on Defining control and Management Planes

Y'all:

So, for example:

:-)

Russ

<><
[email-masked]
Ericsson

---

From: Scott Brim <[email-masked]>
Date: Sun, 10 Nov 2013 13:11:32 -0500

Pardon the delay but now that the IETF is over ...

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.

If you look at it this way, management can manage more than the control
plane - it manages all the functions it has to.  I've seen management for
different planes (and "layers", whatever you mean by them) partitioned, and
only management of the forwarding plane considered to be the management
plane proper -- just as we usually partition forwarding for the control and
management planes from the forwarding plane proper. However you define it,
I believe the essential characteristic is what I said above - management
sets up the machinery and sits back to watch, while control is an essential
part of the functioning of the machinery.

The function of I2RS is to monitor and to set things up so that they will
run right (including both control and forwarding) so I call I2RS
management.  SDN is a multifaceted beast but I would consider most of what
people call SDN to focus on management interfaces, despite the nomenclature
of "controllers" and so on.

Yaakov, I disagree with you about local vs remote. That might have been
true in what you worked on in your formative years but take a look at the
formal modeling in SG15 and some of the SG13 "future network" documents.
 Control vs management - to the extent it matters - is orthogonal to how
close the relationship is.

People are right about functional definitions. A particular package like
netconf is not part of any plane, rather its functions can be distributed
across multiple planes, depending on goals and results.

Scott

---

From: Russ White <[email-masked]>
Date: Sun, 10 Nov 2013 23:35:54 -0500

> 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

<><
[email-masked]
Ericsson

---

From: Yaakov Stein <[email-masked]>
Date: Mon, 11 Nov 2013 09:35:14 +0000

David, 

I believe that the name "centralized control plane" is an oxymoron.

I was just catching up on the emails on this list,
and saw Scott's on the newer ITU-T work.
All I can say is that I don't agree with what has happened since I stopped contributing there.

A few years back I heard in SG13 several people saying that the distinction between
control and management planes had become archaic, and that since the management plane
no longer required manual intervention (since intelligent software performed the management tasks better and more reliably than humans) we should settle on a two-plane model.
This is perhaps what you and Scott (and SDN enthusiasts in general) are proposing.

However, the statement led me to consider what differences there may be between 
two paths, once of which was a configured static route (i.e., set up by management plane),
and the other determined by a routing protocol (i.e., set up by control plane).

My first inclination was indeed that the speed of one vis-à-vis the other
was no longer important, and indeed many "control protocols" now have relatively slow timers.
But the centralized vs. distributed distinction was still in effect, 
which meant some time duration effect, but more importantly a difference in computational strength and consistency.

Distributed routing protocols base themselves on the fundamental tenet of dynamic programming,
that is, that in certain very special cases local decision can lead to a global optimum.
Basically, routing protocols are good at finding basic connectivity, and perhaps optimizing an additive criterion (e.g., hop count), but are dismal at solving more complex tasks.
On the other hand a centralized computation paradigm (assuming on full knowledge at the centralized site), reduces arbitrary routing tasks to computation on graphs, 
which may be NP-complete, but are always, in principle, solvable.

So, could this be the real difference between control and management planes ?
Could a control plane be for "simple" tasks that could be accomplished by distributed protocols,
while the management plane was left for more complex tasks, that required more knowledge to solve ?

But then, why should we use distributed protocols at all ? 
Distributed protocols are at best eventually consistent.
Surely anything that they could do, a centralized platform could do better.
Perhaps they would require more bandwidth (to send the request for computation to the central site) and append additional delay (for the same reason), but surely bandwidth is now cheap and this shouldn't be a major issue.

But then I started considering the fact that the connection to the centralized site may be lost,
and started worrying about availability (the famous five nines), and fault tolerance. Surely there were differences here. When I first heard Brewer's result, it all fell into place.
And the new emphasis of SDN proponents that packet forwarding is a computational problem, provides the justification for applying the CAP theorem in the first place. 

Since then, time and time again I have seen how tasks carried out by veteran service providers in particular ways are all exquisitely fashioned to meet CAP constraints.
This is accomplished by performing some tasks using centralized management, and others using distributed control. The control is always local, simple, automatic (fast), reliable, but not necessarily optimal or consistent; while the management is always consistent, complex, but possibly slow to respond, and sometimes unavailable.

This is not just history. This is a provable corollary of the CAP theorem. 
Eliminating the ability to choose which of the CAP constraints can be ignored for a given task, means losing a crucial tool for service provision and maintenance. 
Those proposing providing high-availability and fault-tolerant services using a centralized architecture (i.e., a management system) don't understand the consequences of the CAP theorem.
Those striving to build "fault-tolerant SDN controllers" are deluding themselves.

Bottom line, there is a need for both a local/distributed system, AND a remote/centralized system.
I think the names control and management are suitable denotations due to historic convention,
but you can rename them as long as you understand their separate purposes.

Y(J)S

-----Original Message-----
From: David Meyer [mailto:[email-masked]] 
Sent: 07 November, 2013 18:38
To: Yaakov Stein
Cc: Russ White; [email-masked]
Subject: Re: [Sdn] Thoughts on Defining control and Management Planes

Yaakov,

On Wed, Nov 6, 2013 at 7:42 PM, Yaakov Stein <[email-masked]> wrote:
> I would like to explain my comment at the meeting on the difference 
> between the two planes, and add something about why the difference between the two is important.

>
> In the olden days, three planes were defined - the data or user (or 
> forwarding) plane, the control plane, and the management plane.
> As an example, OAM messages are user plane (since they fate share with 
> user data), but may trigger control protocol operations such as protection switching, or may trigger alarms (management plane) or be used to collect statistics that can be retrieved via the management plane.
>
> Over time more and more "intelligent" operations that were once 
> performed by humans were replaced by software. However, two fundamental differences remained.
> Second - since humans were localized in NOCs the management 
> intelligence remains centralized, while control protocols are distributed.

Agreed, this is history. But as I mentioned this paradigm (almost
explicitly) no longer really applies (especially in the age of what I would call "deep automation"; see e.g. [0]; but then I think we all know this).

> Because there are operations that are better carried out locally, and 
> there are others that are better managed from a central management site.
>
> I don't have the room to fully explain this here, but the CAP theorem 
> dictates that at most two of consistency, availability, and partition tolerance can be achieved simultaneously.

I highly advise [1] for folks seeking to get some intuition about what the CAP theorem is  all about.

> In general, service providers are required to guarantee availability 
> (e.g., five nines) and partition tolerance (e.g., 50 msec) for 
> operational services, and they forgo consistency (which is why we need OAM and TTL fields).

Proponents of centralized approaches might disagree. Personally it seems almost trivial to see that a lower bound would be something like

where

RTT is the round trip time, and PPT is the packet processing time (note in the case of something like OF you might have sum this over the entire  path).

> However, there are tasks that require consistency and can give up 
> availability, such as new service creation; these require a 
> centralized management system (which is why service activation is slow - it is not immediately available).

> Network operations involves disciplined decision behind the use of one 
> or the other plane for various tasks.
>
> 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).

Yes, nothing new under the sun. However, separation of control and data planes was a key component of what was perhaps early thinking about the attributes of what was then called SDN. See e.g., [2] (or any number of other references). Now, if you are arguing that those definitions were either wrong is fair game, however, that doesn't change the fact that control/data plane separation was a key part of early definitions of SDN.

That is also not clear. I can make the "centralized management plane"
a distributed system as well, at which point the CAP theorem is in play.

Thx,

--dmm

---

From: "Russ White" <[email-masked]>
Date: Mon, 11 Nov 2013 06:25:02 -0500

> Could a control plane be for "simple" tasks that could be accomplished by
> distributed protocols, while the management plane was left for more
> complex tasks, that required more knowledge to solve ?

No, I don't buy this definition, either. Complexity level doesn't
differentiate between the two.

> I think the names control and management are suitable denotations due to
> historic convention, but you can rename them as long as you understand
> their separate purposes.

I think the distinction is "what touches the information used by the data
plane to forward traffic directly." It's simple, direct, and  differentiates
between control functions (like routing protocols, static routes, etc.), and
the management plane (like environmentals, memory, cpu, control plane
operation configuration and parameters, etc.).

We're really struggling to make this theoretical, when what we want is
something that's simple and easy to pin down in 90% of the cases. There
might be hard cases to figure out, but hard cases make bad definitions.

:-)

Russ

---

From: Yaakov Stein <[email-masked]>
Date: Mon, 11 Nov 2013 13:31:24 +0000

Russ

Perhaps we should first agree on specific cases.

I assume that you agree that routing protocols are part of the control plane,
while configuring policies, identifiers, and which protocols to use are management operations.

What about static routes ? Are these management plane ?
According to your definition there aren't (they touch information used by the user plane).
But they can be considered a rather strict policy as to how to handle a specific kind of packet.

What about fault management functions ?
According to conventional wisdom, OAM protocols are user plane (they MUST be, since their purpose is to share fate with user traffic), but they can trigger automatic protection switching or fast reroute (control plane operations), and/or raise alarms (management plane).
But what if I have some software in the OSS that detects that protection switching didn't work,
and forces a switchover. That certainly touches the behavior of the user plane - does that make it control plane ? What if a human made the decision to force a switchover ? Is the human a control plane function ?

Y(J)S

-----Original Message-----
From: Russ White [mailto:[email-masked]] 
Sent: 11 November, 2013 13:25
To: Yaakov Stein; 'David Meyer'
Cc: 'Scott Brim'; [email-masked]
Subject: RE: [Sdn] Thoughts on Defining control and Management Planes

> Could a control plane be for "simple" tasks that could be accomplished 
> by distributed protocols, while the management plane was left for more 

No, I don't buy this definition, either. Complexity level doesn't differentiate between the two.

> I think the names control and management are suitable denotations due 
> to historic convention, but you can rename them as long as you 
> understand their separate purposes.

I think the distinction is "what touches the information used by the data plane to forward traffic directly." It's simple, direct, and  differentiates between control functions (like routing protocols, static routes, etc.), and the management plane (like environmentals, memory, cpu, control plane operation configuration and parameters, etc.).

We're really struggling to make this theoretical, when what we want is something that's simple and easy to pin down in 90% of the cases. There might be hard cases to figure out, but hard cases make bad definitions.

:-)

Russ

---

From: "Russ White" <[email-masked]>
Date: Mon, 11 Nov 2013 08:50:41 -0500

> Perhaps we should first agree on specific cases.

I think we need a general definition based on the underlying assumptions in
devices and protocols already in use. If we propound a few dozen specific
cases, we're going to find we can always build specific models for each one.
The reason I started this thread was to find a single definition that we
could all build on, even if it doesn't fit every situation perfectly. If we
don't have common ground, the only discussion we're going to have is about
which specific case is the most interesting/pertinent/what I have a customer
trying to do/etc. -- a conversation that's not going to lead us anywhere, in
the end.

> What about static routes ? Are these management plane ?

Control plane --they touch the databases used to forward packets directly.

> But they can be considered a rather strict policy as to how to handle a
specific
> kind of packet.

Forget policy for the moment -- part of the problem is we want to merge
different things into a single humongous model that covers the entire ocean
in one sweep. Down that path lies confusion. Break the problem apart, and
deal with each part. Policy is a different problem, a different thread, and
a different definition.

> What about fault management functions ?

First option --

1. The instant removal of local data plane forwarding information from the
forwarding path on a local interface state change, so this would be in the
data plane.

2. The subsequent notification of management and control planes to trigger
processes to modify the data plane forwarding tables, etc. This would seem
to fall into the control plane if the notification is to a control plane
protocol, and into the management plane if the notification is to a
management plane system. IE, reporting for fault management would be
considered management plane, while notification for reconvergence of the
control plane (whether distributed or centralized) would fall into the
control plane. 

I know there's overlap here, but again, hard cases make bad definitions. 

Second option -- 

All messages and protocols are classified on where they originate or "run"
(???). In this case, notifications based on changes to the data plane would
be consider part of the data plane.

I'm ambivalent about which of these two is better, but I tend to think the
second is probably clearer in the long run. 

> According to conventional wisdom, OAM protocols are user plane (they
> MUST be, since their purpose is to share fate with user traffic), but they
can
> trigger automatic protection switching or fast reroute (control plane
> operations), and/or raise alarms (management plane).

Don't worry about whether the management traffic shares fate with the data
plane traffic --again, a different topic. If we reach out into side issues
far enough, we wind up without any meaningful definition, because we can
always find some instance that seems at least tangentially related, and yet
doesn't seem to fit into the definition absolutely. IE, narrowing scope is
the best way to get good definitions. Conventional wisdom is going to get us
just where we are today -- a lot of presentations about interesting stuff,
but no real way to set goals and move towards them, IMHO.

:-)

Russ

---

From: Pedro Martinez-Julia <[email-masked]>
Date: Mon, 11 Nov 2013 15:19:07 +0100

> be consider part of the data plane.

This option *must* not be considered. It is really confusing the terms
and may confuse anyone working with them. The notifications originated
from a network device can never be considered part of the data plane and
the functional block that sends it can never be part of the data plane.

Again, from my point of view, protocol/function classification is very
clear. In a device centric model:
- Data Plane: Those protocols/functions that forward data from incoming
  to outgoing interfaces/ports.
- Control Plane: Those protocols/functions that change the information
  used by the protocols/functions of the data plane (forwarding tables)
  in order to achieve the objectives or general operation of the device.
- Management Plane: Those protocols/functions used to monitor the status
  of a device, set configuration parameters and general policies that
  the device must enforce to achieve its objectives (yes, definition of
  policies is part of the management plane), etc.

The management plane may be a bit "catchall" but all its functions come
from administrative decisions, so it is tied to management operation.

Regards,
Pedro

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 11 Nov 2013 15:28:49 +0100

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

Best,
r.

---

From: "Russ White" <[email-masked]>
Date: Mon, 11 Nov 2013 09:30:51 -0500

> 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 09:33:15 -0500

> This option *must* not be considered. It is really confusing the terms and
> may confuse anyone working with them. The notifications originated from a
> network device can never be considered part of the data plane and the
> functional block that sends it can never be part of the data plane.

Hmm... I can see your point. 

> Again, from my point of view, protocol/function classification is very
clear. In
> a device centric model:

>   policies is part of the management plane), etc.

These are fine with me --only I'd leave "policy" to a different discussion,
just because it's going to need a separate discussion. :-)

:-)

Russ

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 11 Nov 2013 15:33:35 +0100

Well not according to Pedro ... He says that "Those
protocols/functions used to monitor the status  of a device" is a mgmt
plane :)

r.

---

From: Pedro Martinez-Julia <[email-masked]>
Date: Mon, 11 Nov 2013 15:58:53 +0100

> plane in your "very clear" model does it belong ?

For me, th BFD protocol is classified as control plane because it will
affect to the forwarding behavior (if BFD is connected to the device
forwarding tables). The reason for not being part of the data plane is
obvious, it does not forwards packets form other entities. It is not
from a management plane because its objective is not to communicate
administrative decisions.

On the other hand, if BFD is just used to know the health of links, it
can effectively be considered part of the management plane. This can be
an example of how the same protocol may operate for the control plane or
for the management plane, but it does not break the boundaries among the
planes, just demonstrates that the classification should be applied to
running functions/protocols, not to their architecture.

Regards,
Pedro

---

From: Pedro Martinez-Julia <[email-masked]>
Date: Mon, 11 Nov 2013 16:03:36 +0100

> protocols/functions used to monitor the status  of a device" is a mgmt

I've answered your previous mail but in this rough definition, "status"
means the global status of a device and the objective is important so I
can add to the definition that the objective of a function/protocol of
the management plane is to support management/administrative decisions.

Regards,
Pedro

---

From: Yaakov Stein <[email-masked]>
Date: Mon, 11 Nov 2013 17:43:26 +0000

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

> 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: Pedro Martinez-Julia <[email-masked]>
Date: Mon, 11 Nov 2013 19:06:33 +0100

> would out-of-band BFD mean anything ?

It would but you cannot achieve the objective without actually crossing
the link you are testing. However, it is still control plane because the
objective is the control, not to forward data. Remember that packet
content in data plane does mean nothing to intermediate devices, just to
the source and destination.

Regards,
Pedro

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 11 Nov 2013 19:53:35 +0100

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: Pedro Martinez-Julia <[email-masked]>
Date: Mon, 11 Nov 2013 20:06:52 +0100

> there it has really nothing to do with control plane at all.

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.

> Arguing for definition of planes now seems to me pretty pointless :-)

The only interest in classification is to have a clear boundary to place
functionality. Modularization and loose-coupling are key principles that
need such classification to be verified.

Regards,
Pedro

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 11 Nov 2013 20:18:29 +0100

Hi Pedro,

> 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: Pedro Martinez-Julia <[email-masked]>
Date: Mon, 11 Nov 2013 20:24:43 +0100

> Hi Pedro,

Hi,

> I think you on the other hand vastly underestimate it.

Maybe.

> of little use for practical applications.

I agree there are other functions for the data plane but I think it is
better to keep things simple at first. Anyway, most of the functions you
mention do not require to analyze packet content.

Regards,
Pedro

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 11 Nov 2013 20:27:57 +0100

> I agree there are other functions for the data plane

Great !

> but I think it is better to keep things simple at first.

Keep it simple, but not simpler then necessary. Otherwise no one will use it.

> Anyway, most of the functions you

They all require to analyze the packet content. The only questions may
be what depth of the packet inspection and modification during
forwarding is required.

r.

---

From: Scott Brim <[email-masked]>
Date: Mon, 11 Nov 2013 15:20:07 -0500

On Sun, Nov 10, 2013 at 11:35 PM, Russ White
<[email-masked]<javascript:_e({}, 'cvml', [email-masked]');>
> wrote:

> 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.

Scott

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 11 Nov 2013 21:52:10 +0000

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

> 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: Robert Raszuk <[email-masked]>
Date: Mon, 11 Nov 2013 22:58:39 +0100

> It's a protocol that notifies a client, and that client can be a routing
> protocol that would modify forwarding,

Nope ... sorry :)

That would be way too slow. BFD notification to routing protocol is
just side product. BFD #1 goal is to notify forwarding hardware which
switches over to backup path at the line card level without *any*
action from RP. That switchover takes order of single miliseconds in
modern hardware. The detection time is the longest to react to
link/node failure.

Note that backup paths are already pre-programmed and pre-resolved.
Only few 100s of ms later RP takes actions to correct the entries
reinstalling in make before break fashion new products of SPF and new
set of backup paths.

Best,
R.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 11 Nov 2013 21:59:02 +0000

On Nov 11, 2013, at 9:58 AM, Pedro Martinez-Julia <[email-masked]> wrote:

> forwarding tables).

Management functions and protocols can affect the forwarding behavior as well. I think this was mentioned in the meeting as well, in the context of config management of control plane vs. a platform.

> The reason for not being part of the data plane is

Yes.

Does this also help?
http://tools.ietf.org/html/draft-shore-icmp-aup-06#section-4

Thanks,

-- Carlos.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 11 Nov 2013 22:13:13 +0000

>> protocol that would modify forwarding,

Please see http://tools.ietf.org/html/rfc5882#section-4

I understand local optimizations, and certainly BFD's interaction with clients is mostly an implementation issue, but:

http://tools.ietf.org/html/rfc5880
   BFD can be abstracted as a simple service.  The service primitives
   provided by BFD are to create, destroy, and modify a session, given
   the destination address and other parameters.  BFD in return provides
   a signal to its clients indicating when the BFD session goes up or
   down.
http://tools.ietf.org/html/rfc5882

   It is important to remember that the interaction between BFD and its
   client applications has essentially no interoperability issues,
   because BFD is acting in an advisory nature (similar to hardware
   signaling the loss of light on a fiber optic circuit, for example)
   and existing mechanisms in the client applications are used in
   reaction to BFD events.  In fact, BFD may interact with only one of a
   pair of systems for a particular client application without any ill
   effect.
etc.

> reinstalling in make before break fashion new products of SPF and new

See above.

Thanks,

-- Carlos.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 11 Nov 2013 23:23:34 +0100

My comment was not regarding BFD RFC and its interoperability, but to
your point of BFD client being routing protocol as number one. It is
just one of many and for real use case of BFD not the most important
one.

In fact BFD very often brings interface down, then rest of events just
happen. So BFD does not directly communicate in this case with any
routing protocol.

Rgs,
R.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 11 Nov 2013 22:32:24 +0000

Robert,

> just one of many and for real use case of BFD not the most important

You missed my point.

My point was that BFD does not modify forwarding.

My point was that BFD signals its clients, and other functions or protocols (bfd clients) take action.

Your partial mis-quote  of my comment edited out the key elements of my response. Let me try again:

"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". "

Number one? Maybe you misread and were commenting on something you thought you were reading?

> happen. So BFD does not directly communicate in this case with any

Nope.

There is a reason why this draft did not progress:
http://tools.ietf.org/html/draft-shen-bfd-intf-p2p-nbr-00 ("Interface Based Point-to-Point Neighbor BFD")

This draft says:
   This document describes a special application for BFD over
   point-to-point physical or logical circuits. This application
   is not a normal BFD client such as upper layer routing
   protocol, but it is a management element for circuit itself
   where BFD is required and configured.
...
   INTF-P2P Neighbor BFD is an application of BFD [3], the client is
   the interface where BFD service is required. 
Best,

Carlos.

---

From: Sriganesh Kini <[email-masked]>
Date: Mon, 11 Nov 2013 14:34:28 -0800

We seem to be using control-plane and routing-protocols as synonyms.
They are not. Routing protocols are considered part of the control
plane. But that does not mean that the control-plane consists only of
the routing-protocols.

We also seem to restrict control-plane to functionality that runs on
the route-processor cards but rule out any functionality running on
the line-cards. Route-processors cards and line-cards are
implementation/system-architecture components whereas control and
forwarding plane are functional decomposition components.

BFD is control-plane functionality. So is any function (that may exist
on the line-card) that builds structures that are required for
forwarding a packet. This includes actions on say a BFD-down event
that may take place entirely on the line-card. Forwarding-plane is
just the function that is executed when a user-traffic is received. If
the traffic received is control-plane traffic, then all functions
executed once the packet is identified as control-plane traffic, is a
part of control-plane, irrespective of whether it occurs in the
line-card or route-processor-card or any other card in a system.

- Sri

---

From: ramki Krishnan <[email-masked]>
Date: Mon, 11 Nov 2013 15:52:25 -0800

+1, completely agree.

Would like to also add that a control plane functionality like BFD may be implemented in the router through a hardware mechanism such as FPGA for the purposes of linecard software offload.

Thanks,
Ramki

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sriganesh Kini
Sent: Monday, November 11, 2013 2:34 PM
To: Robert Raszuk
Cc: Russ White; Carlos Pignataro (cpignata); SDN IRTF list; Pedro Martinez-Julia
Subject: Re: [Sdn] Thoughts on Defining control and Management Planes

- Sri

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 12 Nov 2013 00:40:32 +0000

Sri,

> forwarding plane are functional decomposition components.

+1.

I very much agree with these two paragraphs.

> forwarding a packet.

Here I disagree. BFD performs fault management for the forwarding plane. It is, by design, decoupled from the control plane (it even has the "C" bit for "Control Plane Independent"). 

http://tools.ietf.org/html/rfc5880#section-2

> This includes actions on say a BFD-down event

BFD can signal to a control plane -- or not. But in itself is not part of the control plane, IMHO.

Thanks,

- Carlos.

---

From: Sriganesh Kini <[email-masked]>
Date: Mon, 11 Nov 2013 17:31:16 -0800

Carlos, see inline

> http://tools.ietf.org/html/rfc5880#section-2

BFD performs fault-notification (not management) so that other
entities can perform useful actions to recover from faults. This even
includes notification to human operators. But mainly it is for the
control-plane so that it can perform the necessary actions so that
forwarding plane only drops as few packets as possible. A good
system-design decouples BFD fate from the route-processor (not the
control-plane). If BFD was always decoupled from the "control-plane"
there wouldn't even be a need to have the C-bit :-)

The C-bit was introduced because some older implementations at that
time had BFD fate-shared with the routing-protocol fate (due to BFD
running on the route-processor) and there was a need to distinguish it
from newer BFD implementations that were not fate-shared with the
routing-protocol fate (due to BFD running on the line-card). The real
requirement was to disentangle BFD and GR state. Note that when C-bit
is not set there is risk of undetected failures as explained in
RFC5880 sec 4.3.2. Strictly speaking, the BFD C-bit being called
control-plane-independent is a misnomer since it wasn't the
control-plane independence but rather the independence from
routing-protocol fate (especially when routing-protocol is in GR
state) that was being expressed. To be blunt there was a need to
prevent the far-end of an older implementation from performing
recovery actions when reloading the route-processor, restarting
processes etc, and an unset C-bit was deployed only after accepting
the risks as described in RFC5880 sec 4.3.2.

- Sri

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 12 Nov 2013 02:23:42 +0000

Hi, Sri,

Interesting useful conversation :-) We may be on a tangent, except for supporting the fact that the definition of terms for these Planes is fuzzy and not so clear... Please see inline.

On Nov 11, 2013, at 8:31 PM, Sriganesh Kini <[email-masked]> wrote:

> entities can perform useful actions to recover from faults.

... or not. Specifically, where does it say "so that other entities can perform useful actions to recover from faults"? Can you please provide a pointer?

I do realize that recovery from faults is a common useful goal. However, BFD performs fault *detection* (not notification), a subset of fault management, but not "in order to recover" necessarily. A perfectly valid use of BFD is to trigger a log or notification (not an action to recover). Less useful, sure (depending the case). Valid, yes as well.

The Abstract of bfd-base is quite unambiguous:

Abstract

   This document describes a protocol intended to detect faults in the
   bidirectional path between two forwarding engines, including
   interfaces, data link(s), and to the extent possible the forwarding
   engines themselves, with potentially very low latency.  It operates
   independently of media, data protocols, and routing protocols.

BFD, intended to detect forwarding plane faults, AKA fault detection. BFD is part of the IETF's OAM toolset.

> This even
> forwarding plane only drops as few packets as possible.

Mainly? My only point is that from a functional perspective, BFD is not data plane and not control plane. It detects data plane failures and (typically, yet not necessarily) informs the control plane. The "D" in BFD for detection, it's not "R" for Restoration/Recovery. BFD does interact with control protocols for recovery.

> A good

Yes, should be called 'GR routing-protocol independent" -- with the only nit that this is actually in RFC 5882 (not 5880) Section 4.3.2.

Thanks,

-- Carlos.

---

From: Sriganesh Kini <[email-masked]>
Date: Mon, 11 Nov 2013 23:52:00 -0800

Hi Carlos, see inline.

> Interesting useful conversation :-) We may be on a tangent, except for supporting the fact that the definition of terms for these Planes is fuzzy and not so clear... Please see inline.

I don't believe the definitions are fuzzy. I hope they are becoming
clearer through this useful conversation.

> On Nov 11, 2013, at 8:31 PM, Sriganesh Kini <[email-masked]> wrote:

[snip]

> ... or not. Specifically, where does it say "so that other entities can perform useful actions to recover from faults"? Can you please provide a pointer?

Maybe not in those words but if you see RFC 5882 intro "...provides a
liveness detection mechanism that can be utilized by other network
components for which their integral liveness mechanisms are either too
slow, inappropriate, or nonexistent". Those other network components
perform actions to recover from faults.

> I do realize that recovery from faults is a common useful goal. However, BFD performs fault *detection* (not notification), a subset of fault management, but not "in order to recover" necessarily.…

Note that in your use-case too you used ".. to trigger a log or
notification". The purpose of these is also to do a recovery. This
recovery may not be your sub-50msec switchover type of recovery. It
could be a "send a line-man to check if/why the fiber is broken and
fix it" or "re-engineer traffic to take into account this broken link"
kind of network recovery. But it is a form of recovery action.

> BFD, intended to detect forwarding plane faults, AKA fault detection. BFD is part of the IETF's OAM toolset.

This does not imply that it is not a control-plane function.

> Mainly? My only point is that from a functional perspective, BFD is not data plane and not control plane. It detects data plane failures and (typically, yet not necessarily) informs the control pla…

I agree that BFD protocol machinery is specified for detection,
however the purpose (as explained by referencing RFC 5882 above) is
for recovery. Similar to the liveness mechanisms of routing-protocols
(that BFD improves upon) being considered control-plane, so too BFD is
control-plane.

So I agree that BFD is not forwarding/data plane. But I disagree that
it is not control-plane.

> Yes, should be called 'GR routing-protocol independent" -- with the only nit that this is actually in RFC 5882 (not 5880) Section 4.3.2.

Thanks for fixing the typo.

- Sri

[snip]

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Tue, 12 Nov 2013 09:55:02 +0100

Hi,

> port it should be forwarded.

No, I disagree. I would attribute DiffServ QoS mechanisms (e.g.,
multifield classifier, token buckets, marker, scheduling mechanisms)
clearly to the data plane. Usually it's up to the control plane
to set those mechanisms up for individual flows. The management plane
part would be resource partioning, i.e., assigning link bandwidth
shares to the individual per-hop behaviors and so on.

Regards,
 Roland

---

From: Pedro Martinez-Julia <[email-masked]>
Date: Tue, 12 Nov 2013 10:21:20 +0100

Hi,

> shares to the individual per-hop behaviors and so on.

Those mechanisms are part of the data plane and they do not break the
definition I gave. They may analyze the content of packets but just for
supporting the forwarding task. It does not mean anything to the device
or functional block that analyzes the packet. On the other hand, control
plane traffic does mean something to the functional block that processes
the packets.

Regards,
Pedro

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 12 Nov 2013 07:17:58 -0500

So one thing we struggled with, and seems related to this thread,  was what
to call an application that sits on an FE/Line card/switch. Consider for example
an app that is offloading ARP or one that is offloading OSPF hellos. It sits in
the line card. On occasion it updates something to the CE. I dont know what
you want to call such a thing which is a helper to some control application.
We called it an application.

cheers,
jamal

---

From: "Russ White" <[email-masked]>
Date: Tue, 12 Nov 2013 08:22:41 -0500

> > plane. But that does not mean that the control-plane consists only of

I hope not... What I think we need is a device centric, functionally based
model of these different planes. We don't want:

- Time based models, because timing changes over time with capabilities and
requirements, and because we want to be able to understand what the timing
requirements are, rather than assuming them in the definition. With a time
based model, if you ask, "how long should it take for a control plane to
converge and update the data plane," the answer is, "if it converges in less
than x ms, then it's all data plane." That answer simply doesn't convey any
useful information.

- Service based models, because services must know what to control to build
the service they want to create. But unless we know what an actual
forwarding device looks like in terms of function, we can't figure out the
interfaces and dynamics of actually modifying that forwarding device. So we
need service based models, but we definitely need a device centric
functional model for the service models to interact with.

- Network based models --same as the service based models above.

I specifically don't want us to consider where the process runs, how long it
takes, whether a human is (or has traditionally been) involved or not, what
services are being offered, what role this device plays in the overall plan
of the network, etc. The only question that should matter in a model that
will actually help us understand what an individual forwarding device looks
like is:

What does this process or protocol do in relationship to the action of
forwarding packets?

Certainly we can disagree about where any particular protocol fits into such
a model, but none of that should invalidate the model -- it should simply
help us understand the interactions between the pieces better. In fact, the
entire discussion over BFD is centered around what BFD does, and how it
interacts with other stuff -- not on its place in a larger scheme of
services, or "because it's so fast, it must be data plane," etc. In other
words, we're implicitly assuming a device centric functionality based model
in our heads in the process of arguing for the non-usefulness of just such a
model.

Once we have a device centric functional model in place, then we can build a
plethora of service and network models, and see how they interact --what
interfaces there need to be, what those interfaces need to look like,  the
timing between the interfaces, what happens if we try and build two
different service models on top of a single physical network, etc. If we
start with a services or network model, we're all going to be propounding
different devices with different capabilities and different interfaces to
get to our favorite set of services --and we'll end up with no actual set of
common api's or idea what one device sitting in an actual rack forwarding
real packets would need to do in relation to the plethora of service and
network models we've created. If we start with a time based model, we're
going to end up with a mash of stuff all in the data plane, because someone
can always think of at least one solid use case to make any given
monitoring, configuration, or any other task as fast as actually switching a
packet.

The reason our presentations are all over the place is that we're all
working from different models in different worlds --we need a point of
contact (or context) where all the models meet and interact, so we can see
how to actually build real networks with this stuff. Until we get there,
we're going to be out wandering the weeds.
	
:-)

Russ

---

From: "Russ White" <[email-masked]>
Date: Tue, 12 Nov 2013 08:31:14 -0500

> 	> For me the difference is between something that is supposed to be
> in continuous operation, and something that is supposed to set up that
right.
> 
> 	I think this merges the control and data planes, though -- and I
think
> we want to be able to differentiate between them.
> 
models.
> Just keep in mind that components function in multiple planes
> simultaneously.

Given your definition --these things are all in continuous operation, so
they must all be control plane:

- Forwarding of packets
- Detection of down links
- Flooding and maintenance of topology information
- Monitoring of cpu thermals
- Monitoring of memory utilization
- Logging
- Reactive configuration to black hole attacks

So these are all control plane --what, precisely, is the data plane or even
the  management plane? If I ask, "Is link utilization monitoring control or
management plane (since this model doesn't have a data plane)," the answer
is, "It depends on whether or not the process monitoring the link
utilization is push or pull." That doesn't make any sense to me --it doesn't
convey useful information on which I can try to understand the relationship
between the moving parts involved.

:-)

Russ

---

From: tim copley <[email-masked]>
Date: Tue, 12 Nov 2013 07:56:19 -0700

So I've been giving this a lot of thought during this discussion and I
think what the problem is that BFD can be used in multiple "planes"
My thinking was swayed both ways, and what I eventually came to
was the realization.

It can be used in the data plane to stop traffic or pull an interface down
It can be used in the control plane, buy feeding information to a Routing
protocol or actually be a part of the routing protocol that will make a
control plan decision
It can be used as information feed to a management plane.

Perhaps it is as somebody said that it's the function performed. BFD
is just one of the tools in our toolbox for providing information into our
SDN system.  But I thought we were building models?

TimC
-- 
"Speed is fine, but accuracy is final." Wyatt Earp, 1888

---

From: Pedro Martinez-Julia <[email-masked]>
Date: Tue, 12 Nov 2013 16:29:06 +0100

> between the moving parts involved.

Those functions/operations are not all part of the control plane. The
difference between the control plane and the management plane is that
the former is *required* by the network (or its individual devices) to
work as expected while the management plane is not strictly required but
permits to know the status and to define the *expected* behavior of the
network (or, also, individual devices).

Regards,
Pedro

---

From: David Meyer <[email-masked]>
Date: Tue, 12 Nov 2013 07:44:57 -0800

> network (or, also, individual devices).

This is at the very least arguable. For example, if I configure
devices with some "management" interface will the network work as
expected say, without IP addresses on the interfaces?

--dmm

---

From: Pedro Martinez-Julia <[email-masked]>
Date: Tue, 12 Nov 2013 16:55:30 +0100

> expected say, without IP addresses on the interfaces?

I do not understand exactly what point are you meaning. If you configure
a device, you are telling the device what are your expectations. If the
configuration is wrong or partial, you are actually telling the device
to work wrong or not to work (as you did not finish the configuration).

Regards,
Pedro

---

From: David Meyer <[email-masked]>
Date: Tue, 12 Nov 2013 08:07:56 -0800

> network (or, also, individual devices).

What I was driving at is defining something as "required" doesn't seem
to help because the same discussion we've been having can be had in
terms of required or not required. In addition, terms like "expected"
behavior also not well defined. In addition the definition of
"required" is confusing: the control plane is "required by the network
to work as expected" while at the same time the management plane is
used to "define the "expected" behavior...".

--dmm

---

From: Pedro Martinez-Julia <[email-masked]>
Date: Tue, 12 Nov 2013 17:21:23 +0100

> used to "define the "expected" behavior...".

I understand your point now. See this example:

You buy, for example, a router and you plug it to your network without
doing anything. In most cases, it will not do what you want it to do.
Then you use a management application, which uses the "management plane"
to interact with the device, and set the router with the addresses and
the routing protocol it has to use. Then, without your intervention, the
router will find other networks, routes, etch.

In this example you can see that without the routing protocol, the
device will not do what you want it to do, so the routing protocol in
this example is "required" and it should be continuously running.
However, after your initial configuration (or if the router comes
pre-configured), unless there is a problem or a decision to change the
operation, you will not have to use the "management plane" again.

This is just to clarify my point. Feel free to read it without the words
"required" or "expected behavior" but I think that the meaning, that can
be more or less abstract, is clear.

Regards,
Pedro

---

From: David Meyer <[email-masked]>
Date: Tue, 12 Nov 2013 08:32:15 -0800

> router will find other networks, routes, etch.

Not if its an OpenFlow router...

> operation, you will not have to use the "management plane" again.

I get what you are saying. Somehow in your definition the control
plane carries out an intended policy instantiated by the management
plane. So long as there is no change in policy you don't need to run
the management plane again. This seems to be back to the idea of
persistent vs. ephemeral state...(the control plane installs ephemeral
state, the management installs persistent state, right up until you
have i2rs...).

--dmm

---

From: Francisco Javier Ros Muñoz <[email-masked]>
Date: Tue, 12 Nov 2013 18:27:33 +0100

Hi David,

> Not if its an OpenFlow router...
I'd say that you still have differentiated management and control protocols in this case:
Management: CLI, OF-CONFIG, OVSDB, etc
Control: OF

Best,
fran

--
Francisco J. Ros, PhD
Dept. of Information and Communications Engineering
University of Murcia, Murcia (Spain)
http://masimum.inf.um.es/fjrm/

---

From: Yaakov Stein <[email-masked]>
Date: Tue, 12 Nov 2013 17:54:27 +0000

Like all OAM functions, they are linked to the layer or plane they monitor.

So there IS control plane OAM, but it is not the BFD that fate shares with the data,
it consists of the keepalive messages protocol of the control protocol,
which fate share with the control messages.

And similarly, the management plane has its own OAM.

If the control or management plane messages travel over different links
from the data traffic, their OAM travel those links as well.

Y(J)S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Pedro Martinez-Julia
Sent: 11 November, 2013 20:07
To: [email-masked]
Subject: Re: [Sdn] Thoughts on Defining control and Management Planes

On Mon, Nov 11, 2013 at 05:43:26PM +0000, Yaakov Stein wrote:
> No, BFD is data plane.
> 
> Control plane protocols can be sent out-of-band; would out-of-band BFD 
> mean anything ?
>

It would but you cannot achieve the objective without actually crossing the link you are testing. However, it is still control plane because the objective is the control, not to forward data. Remember that packet content in data plane does mean nothing to intermediate devices, just to the source and destination.

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

---

From: Sriganesh Kini <[email-masked]>
Date: Tue, 12 Nov 2013 09:57:04 -0800

Keep aside the implementation specific (i.e. "sits on an FE/Line
card/switch") and see what its function is. From your description of
the function I would classify that "application" as part of the
control-plane.

[snip]

---

From: Yaakov Stein <[email-masked]>
Date: Tue, 12 Nov 2013 18:00:45 +0000

> can effectively be considered part of the management plane.

No, that is maintenance (which is what the M in OAM stands for), not management.

Y(J)S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Carlos Pignataro (cpignata)
Sent: 11 November, 2013 23:59
To: Pedro Martinez-Julia
Cc: SDN IRTF list
Subject: Re: [Sdn] Thoughts on Defining control and Management Planes

> The reason for not being part of the data plane is obvious, it does 
> not forwards packets form other entities. It is not from a management 
> plane because its objective is not to communicate administrative 
> decisions.
> 
> can effectively be considered part of the management plane. This can 
> be an example of how the same protocol may operate for the control 
> plane or for the management plane, but it does not break the 
> boundaries among the planes, just demonstrates that the classification 
> should be applied to running functions/protocols, not to their architecture.

Yes.

Does this also help?

Thanks,

-- Carlos.

---

From: Yaakov Stein <[email-masked]>
Date: Tue, 12 Nov 2013 18:04:35 +0000

Carlos,

I agree with most of what you say here.

BFD is a data plane OAM function,
which can trigger control plane functions.

It may have a management plane function to configure it (e.g., by setting values in the BFD MIB),
and it may store counters for the management plane to retrieve (e.g., via SNMP).

Y(J)S

From: [email-masked] [mailto:[email-masked]] On Behalf Of Carlos Pignataro (cpignata)
Sent: 12 November, 2013 00:32
To: Robert Raszuk
Cc: Russ White; SDN IRTF list; Pedro Martinez-Julia
Subject: Re: [Sdn] Thoughts on Defining control and Management Planes

Robert,

On Nov 11, 2013, at 5:23 PM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

You missed my point.

Nope.

This draft says:

   INTF-P2P Neighbor BFD is an application of BFD [3<http://tools.ietf.org/html/draft-shen-bfd-intf-p2p-nbr-00#ref-3>], the client is

Carlos.

Rgs,
R.

On Mon, Nov 11, 2013 at 11:13 PM, Carlos Pignataro (cpignata)
<[email-masked]<mailto:[email-masked]>> wrote:

On Nov 11, 2013, at 4:58 PM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

Nope ... sorry :)

See above.

Thanks,

-- Carlos.

Best,
R.
_______________________________________________
sdn mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/sdn

---

From: Francisco Javier Ros Muñoz <[email-masked]>
Date: Tue, 12 Nov 2013 19:39:30 +0100

Hi everyone,

Ahh, terminology... it has killed some WGs in the past :-)
I'm not very keen on spending too many WG cycles on terminology issues, but it seems that there are quite different understandings out there. Assuming that we really need such definitions, I agree with Russ on the way to go to achieve them.

So here's my view, although I'm not sure if it adds something given that I've had to skim some emails in order to catch up with this thread:

* The Management Plane is responsible for the configuration and monitoring of data plane (ports, queues, etc) and control plane (routing, QoS, filtering, etc) resources.

* The Control Plane is responsible for determining the fate of packets that enter the device. Each packet belongs to a specific forwarding group (equivalence class) depending on its content. For each forwarding group, the Control Plane decides whether such packets must be dropped or forwarded. If the decision is to forward the packets, the control plane establishes the appropriate output port(s), the treatment that packets receive while buffered within the device, and the required actions on their protocol headers before they leave the device.

* The Data Plane inspects incoming packets in order to classify them into a forwarding group as specified by the Control Plane. After classification, the Data Plane implements the corresponding actions that have been determined by the Control Plane for that forwarding group.

Obviously, the former applies to both physical and virtual devices.

My two cents,
fran

---

From: Scott Brim <[email-masked]>
Date: Wed, 13 Nov 2013 09:33:34 -0500

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

> 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

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

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

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 13 Nov 2013 16:07:17 +0000

> network (or, also, individual devices).

I do not think this definition can stand much test. Part of the problem from my perspective is that "*required*" needs further qualification. For example, I'd suggest that gathering stats for billing customers would be argued as "required by the network to work as expected" by a service provider. If a device calls home / an NMS to bootstrap something, is that control plane? What about management interfaces of defices?

Just my $0.02.

-- Carlos.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 13 Nov 2013 16:35:05 +0000

Hi, Sri,

Thanks for the follow-up, please see inline.

> clearer through this useful conversation.

I think that, net-net, we still do not have "definitions". I do agree that things are becoming clearer and the conversation is useful.

> perform actions to recover from faults.

I guess the difference boils down to the scope of the system you are including. This quoted text basically says, that other functions/systems that do not inherently have a good liveness mechanism can use BFD, as clients to it.

Basically, if you consider BFD as always a sub-system of a larger system that includes, say, a routing protocol, the overall system performs a control plane function. If BFD always notifies some system to take a specific action, you are not talking about BFD but the superset. But if, instead of merging and coalescing, you treat BFD as an atomic protocol with APIs to other functions, it gets more tricky.

Further, RFC 5882 defines an application of BFD, not the protocol itself, and "can be utilized" to me says "can be utilized, or cannot, and can be utilized for something else".

> This does not imply that it is not a control-plane function.

I agree, not implication meant. But I did want to call out the part that says "it operates independently of ... routing protocols".

> So I agree that BFD is not forwarding/data plane. But I disagree that

Maybe BFD does not have a plane unless it's applied to some function, in which case it can be part of control plane as OAM for routing protocols, or something else.

Thanks,

-- Carlos.

---

From: Alan Clark <[email-masked]>
Date: Wed, 13 Nov 2013 13:13:01 -0500

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] 
> <mailto:[email-masked]>> wrote:
>
>
>     > function, then you can sit back and watch to make sure you did
>     it right.
>     A
>     > Russ, maybe it merges your concepts of planes, but I'm trying to
>     get you
>     to
> 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
> 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.)
>
> 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.
>
> 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
>
>

---

From: Sriganesh Kini <[email-masked]>
Date: Wed, 13 Nov 2013 12:24:22 -0800

Hi Carlos,

[snip]
> I think that, net-net, we still do not have "definitions". I do agree that things are becoming clearer and the conversation is useful.

As things become clearer, I am sure the definitions will follow.

[snip]
> I guess the difference boils down to the scope of the system you are including. This quoted text basically says, that other functions/systems that do not inherently have a good liveness mechanism c…

Agree. Liveness test mechanisms are control-plane functions

> Basically, if you consider BFD as always a sub-system of a larger system that includes, say, a routing protocol, the overall system performs a control plane function. If BFD always notifies some sy…

The fact that an entity has an API should not change which plane it belongs to.

> Further, RFC 5882 defines an application of BFD, not the protocol itself, and "can be utilized" to me says "can be utilized, or cannot, and can be utilized for something else".

It there are other uses, I would like to see the related applicability RFC.

[snip]
> I agree, not implication meant. But I did want to call out the part that says "it operates independently of ... routing protocols".

True. And since a control-plane consists of more than just the
routing-protocols ....

[snip]
> Maybe BFD does not have a plane unless it's applied to some function, in which case it can be part of control plane as OAM for routing protocols, or something else.

Right on ! With the exception that if BFD is not applied to any
function then one has to ask "If a tree falls in a forest ..."   :-)

Thanks
- Sri

[snip]