Subject: Re: [Sdn] Timeliness WAS(Re: Thoughts on Defining control andManagement Planes

From: Russ White <[email-masked]>
Date: Wed, 13 Nov 2013 10:01:02 -0600

==
> Control processes are automatic, triggered by events and timers,
> and the logic behind them straightforward.
> Management operations are initiated, and are directly motivated by
> high-level (business/mission related) concerns.
>

Dont agree 100% but it is the closest thing I have heard
to what we have been trying to say.
==

Don't agree... It doesn't matter what initiates the action, it matters what the functionality is. Defining this by what initiates means processes and functions move as where they are initiated from. A static route to implement policy is management, while a static route to create a forwarding path is control plane -- down this path lies confusion.

A functional model, not an intentional model.

:-)

Russ

-----Original Message-----
From: "Jamal Hadi Salim" <[email-masked]>
Sent: ‎11/‎13/‎2013 7:51 AM
To: "Yaakov Stein" <[email-masked]>
Cc: "Russ White" <[email-masked]>; "David Meyer" <[email-masked]>; "[email-masked]" <[email-masked]>
Subject: Re: [Sdn] Timeliness WAS(Re: Thoughts on Defining control andManagement Planes

On Wed, Nov 13, 2013 at 2:02 AM, Yaakov Stein <[email-masked]> wrote:
> No, a management plane operation doesn't become a control plane
> one just because it is faster.
>

Indeed.
I think the timeliness factor is already being proven of importance
by desire to make netconf move faster. Netconf is a protocol that
was designed to be management. And it is now used in some
cases to do control operations - it is natural to think its timeliness
needs to improve (as that draft tries to).

> In general, control plane operations are faster because they are local >rather than having to suffer a round-trip time, or because they are >automatic rather than having a human in the loop.
>

Is going a cross a small number of hops local (CE<-->FE)?

> But there are exceptions. Configuring using a terminal directly plugged into >a box is management plane, although it is very local.
>

Agreed.

> Control processes are automatic, triggered by events and timers,
> and the logic behind them straightforward.
> Management operations are initiated, and are directly motivated by
> high-level (business/mission related) concerns.
>

Dont agree 100% but it is the closest thing I have heard
to what we have been trying to say.

cheers,
jamal

---

From: Russ White <[email-masked]>
Date: Wed, 13 Nov 2013 10:07:28 -0600

To put it another way --"what does it do?," not, "who does this?"

:-)

Russ 

-----Original Message-----
From: "Jamal Hadi Salim" <[email-masked]>
Sent: ‎11/‎13/‎2013 7:51 AM
To: "Yaakov Stein" <[email-masked]>
Cc: "Russ White" <[email-masked]>; "David Meyer" <[email-masked]>; "[email-masked]" <[email-masked]>
Subject: Re: [Sdn] Timeliness WAS(Re: Thoughts on Defining control andManagement Planes

Indeed.

Agreed.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 14 Nov 2013 07:17:09 -0500

I dont think "What does it do?" is sufficient Russ.

Given we are talking about existing interfaces and not inventing
new ones,  our starting point is/was to ask of an interface
"What was it intended to do?"
which lead us to "What do i want to use it for?". This is all in
the background  of the hype around the SDN terrain. We are
not trying to be judge/jury/executor about what SDN is (if you
are selling expect scripts around CLIs as SDN, hey that is SDN too)
but we felt it was important to provide distinguishing characteristics
in order to provide coloring or shades of grey on the SDN landscape.
>From that perspective, it then becomes important to reference
what the design intent and _history_  of an interfaces are in order
to provide a reasonable taxanomy as context to answer the above
question.

Example:
1) Netconf was _intended_ to be an interface for management/config.
Common "management" interfaces were at play.
It was _intended to be human friendly and have a human loop.
Those are the requirements it was optimized for.

2) ForCES was intended to be a control interface.
It was intended to have low latency in control updates
and have high throughput in bulk table updates.

You can use both ForCES and netconf to do FIB table updates.
But that detail does not qualify  the "what do i want to use it for?"

where the "I" is the brainy part - lets call it app (its execution
location is not important, can sit on a switch/control engine etc).
My control/management app/brain activity is not necessarily tied to
one interface. I may use a reachability change from a management
interface(BFD)  to invoke a control activity that deletes or adds a
table entry (ForCES).

The collision course is when there is conflict of intent between
"What" an interface was intended to achieve and the intent
of "who" is using it. This is the crux of the issues. The conflict
needs to be described via attributes. Timeliness is one.

cheers,
jamal

On Wed, Nov 13, 2013 at 11:07 AM, Russ White <[email-masked]> wrote:
> ________________________________
> From: Jamal Hadi Salim
> Sent: 11/13/2013 7:51 AM
> To: Yaakov Stein
> Cc: Russ White; David Meyer; [email-masked]
>> In general, control plane operations are faster because they are local
>> >rather than having to suffer a round-trip time, or because they are
>> >automatic rather than having a human in the loop.
>>
>
>> But there are exceptions. Configuring using a terminal directly plugged
>> into >a box is management plane, although it is very local.
>>
>
> Agreed.
>