Subject: [Sdn] Reference Layer Model

From: Roland Bless <[email-masked]>
Date: Thu, 06 Mar 2014 11:19:19 +0100

Hi,

some remarks w.r.t. slide 7 of
http://www.ietf.org/proceedings/89/slides/slides-89-sdnrg-6.pdf

1.) (related to Scott Brim's comment)
I guess what cause slight confusion was the fact that two boxes
in the middle (control/management) are labeled Control Plane and
Management Plane. They are rather (logical) entities residing
in the respective planes, e.g., the Control Plane is made up of
a set of Control Entities working together. So Control Plane
and Management Plane should not be written _into_ the boxes
(maybe beneath).
Even more confusing are the blocks "Forwarding Plane"  and "Operational
Plane" inside the network device, their are rather entities/functional
blocks belonging to these planes.

2.) (related to Dirk Kutscher's comment)
Sometimes Management Plane actions may trigger related control actions,
so some (optional) horizontal interaction between the two boxes in the
middle is missing IMHO, too.

Regards,
 Roland

---

From: Dirk Kutscher <[email-masked]>
Date: Thu, 6 Mar 2014 10:53:00 +0000

Hi,

For illustrating the different and relationship of control and management plane,  wouldn't the approach in figure 1 of
https://www.opennetworking.org/images/stories/downloads/sdn-resources/technical-reports/SDN-architecture-overview-1.0.pdf

be applicable here?

Best regards,
Dirk

> -----Original Message-----
> From: sdn [mailto:[email-masked]] On Behalf Of Roland Bless
> Sent: Donnerstag, 6. März 2014 11:19
> To: [email-masked]
> Subject: [Sdn] Reference Layer Model
> 
> Hi,
> 
> I guess what cause slight confusion was the fact that two boxes in the middle
> (control/management) are labeled Control Plane and Management Plane.
> They are rather (logical) entities residing in the respective planes, e.g., the
> Control Plane is made up of a set of Control Entities working together. So
> Control Plane and Management Plane should not be written _into_ the
> boxes (maybe beneath).
> Plane" inside the network device, their are rather entities/functional blocks
> belonging to these planes.
> 
> 2.) (related to Dirk Kutscher's comment) Sometimes Management Plane
> actions may trigger related control actions, so some (optional) horizontal
> interaction between the two boxes in the middle is missing IMHO, too.
> 
> Regards,
>  Roland
> 
> _______________________________________________
> sdn mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/sdn

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 6 Mar 2014 06:11:43 -0500

To Roland's point:
The boxes on management and control are abstractions.
One could implement management using control interfaces.
I believe this is one of the disclaimers in the draft and one of the
slides Evangelos put up.
I think this is one of the challenges that needs to be addressed to
have some coherency as to what control vs management boundary is.
The current theme on the list seems to be: ephemeral state vs config.

Response to Dirk inline.

> https://www.opennetworking.org/images/stories/downloads/sdn-resources/technical-reports/SDN-architecture-overview-1.0.pdf

I think this document is mentioned in the latest release of the draft.
Looks similar conceptually but in my view not abstract enough; example
leaving out
Management may be a good fit for ONF but not IETF.

cheers,
jamal

---

From: Scott Brim <[email-masked]>
Date: Thu, 6 Mar 2014 16:03:06 +0000

> blocks belonging to these planes.

I believe it's okay to have the management and control planes in
abstract small boxes in the center of the diagram. At this level of
abstraction that works just fine. It's also okay to have the
forwarding plane in such a box. I believe it's fine to have the
forwarding plane below the control plane, since there is a clear
relationship along that axis BUT the DAL is for both management and
control, so don't let the diagram imply that forwarding interacts only
with the control plane.

The problem comes from trying to create symmetry in the diagram by
inserting an operational "plane" below the management plane.  It's
not. But neither is it just a piece of the management plane.

I recommend considering the operational functions to be terminations
of either/or/both of the management and control planes. It's not one
in particular, it's an aggregate, a high level abstraction. Just call
that box something like "operations" -- something that doesn't imply
which particular plane it's associated with, and fix the associated
text and slides. That way, the abstraction is all on the same level,
and works.

Scott