Subject: [Sdn] FW: New Version Notification for draft-haleplidis-sdnrg-layer-terminology-00.txt

From: "Haleplidis Evangelos" <[email-masked]>
Date: Tue, 16 Jul 2013 14:27:56 +0300

Greetings to all,
       
We have submitted the following draft regarding layer taxonomy for SDN.
Comments and suggestions are welcome.

Regards,
Evangelos Haleplidis.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, July 15, 2013 10:34 PM
> To: Spyros Denazis; Odysseas Koufopavlou; Kostas Pentikousis; Evangelos
> Haleplidis; Jamal Hadi Salim
> Subject: New Version Notification for draft-haleplidis-sdnrg-layer-
> terminology-00.txt
> 
> 
> A new version of I-D, draft-haleplidis-sdnrg-layer-terminology-00.txt
> has been successfully submitted by Evangelos Haleplidis and posted to
> the IETF repository.
> 
> Filename:	 draft-haleplidis-sdnrg-layer-terminology
> Revision:	 00
> Title:		 SDN Layers and Architecture Terminology
> Creation date:	 2013-07-15
> Group:		 Individual Submission
> Number of pages: 13
> URL:             http://www.ietf.org/internet-drafts/draft-haleplidis-sdnrg-layer-terminology-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-haleplidis-sdnrg-layer-terminology
> Htmlized:        http://tools.ietf.org/html/draft-haleplidis-sdnrg-layer-terminology-00
> 
> 
> Abstract:
>    Software-Defined Networking introduces an abstraction layer and by
>    doing so separates the Forwarding from the Control layer.  This
>    separation can allow faster innovation cycles at both layers as
>    experience has already shown.  However, there is increasing
> confusion
>    as to what exactly SDN is, what is the layer stucture in an SDN
>    architecture and how do layers interface with each other.  This
>    document aims to provide a concise reference for future discussions
>    in SDNRG.
> 
> 
> 
> 
> The IETF Secretariat

---

From: David Meyer <[email-masked]>
Date: Tue, 16 Jul 2013 07:27:49 -0700

Evangelos,

Nice start. Search for dmm> in-line in the attached for my comments.
Among other things I'll just note here that there is a terminology
skew with the OpenDaylight project and the use of Service Abstraction
Layer (or SAL). See
http://www.opendaylight.org/project/technical-overview.

Thanks,

--dmm

On Tue, Jul 16, 2013 at 4:27 AM, Haleplidis Evangelos <[email-masked]> wrote:
> _______________________________________________
> sdn mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/sdn

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 16 Jul 2013 10:39:46 -0400

Dave,

I think the usage of Service Layer in the opendaylight
diagram does not look correct if you are going to be using that
interface talk to control protocol abstractions. What you have
there is a control abstraction layer.
OTOH, I see what you label as "OpenDaylight APIs" are a service layer
abstraction.

Could you please call out ForCES in your diagram? We need the
visibility.

cheers,
jamal

On Tue, Jul 16, 2013 at 10:27 AM, David Meyer <[email-masked]> wrote:

> >> URL:
> http://www.ietf.org/internet-drafts/draft-haleplidis-sdnrg-layer-terminology-00.txt
> >> Status:
> http://datatracker.ietf.org/doc/draft-haleplidis-sdnrg-layer-terminology
> >> Htmlized:
> http://tools.ietf.org/html/draft-haleplidis-sdnrg-layer-terminology-00
> >>
> >>
> >> Abstract:

---

From: David Meyer <[email-masked]>
Date: Tue, 16 Jul 2013 07:45:37 -0700

[copying in [email-masked]]

> OTOH, I see what you label as "OpenDaylight APIs" are a service layer

I understand your perspective, and we need to have this discussion.
Thank you folks for opening it up.

> Could you please call out ForCES in your diagram? We need the

So OpenFlow is called out because (I would imagine) that is the only
plugin we have at the moment. ForCES would be captured by "IETF". That
said, this is one of the early architecture diagrams and it may make
sense to discuss some kind of harmonization. BTW, I'm sure the ONF has
its own terminology as well, so it does make sense to use the same
terminology when we're talking about the same objects.

--dmm

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 16 Jul 2013 11:28:24 -0400

> Thank you folks for opening it up.

OD may be collapsing everything that exists downwards under "services
layer". I think architecturally this would be an issue given there are many
different semantics.
I havent looked at OD details, but one characteristics (on the
control/management
plane) that is obvious is as you towards services the APIs become more
coarse
grained and as you go down towards for example a control API, it gets more
fine
grained.

> plugin we have at the moment. ForCES would be captured by "IETF".

Fair enough if the diagram is intended to illustrate what you have today.
But do note we are a control-datapath separation architecture. The second
closest thing for that out of IETF is GSMP. Maybe you need to separate
what is config, management, control etc out of the IETF.

That
> terminology when we're talking about the same objects.

My experience is it would be hard to get everyone to agree. The draft
posted by Evangelos should hopefully help amalgamate things.

cheers,
jamal

PS: OD, Java? Why? Python, maybe. Go perhaps.
Java maybe there for historical reasons perhaps?

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 16 Jul 2013 19:01:44 +0200

On 7/16/13 4:27 PM, David Meyer wrote:
> 2.4.  Service Abstraction Layer
>
>     The Service Abstraction Layer (SAL) provides access from services of
>     the control, management and applciation plane to services and
>     applications of the application plane.  Examples of service
>     interfaces are REST APIs.
>
> dmm> again, there is a terminology skew with ODP
> dmm> (http://www.opendaylight.org/project/technical-overview)
> dmm> We should harmonize these.

I also think that would be great to harmonize the terminology for 
Service and Application,
but we should also clarify and specify it much better.

what really means a statement like

	 Examples of service interfaces are REST APIs.

REST is just a way, the most popular, to design API in the WEB environment.
Not all the REST API are supposed to be SDN North Bound interface and 
the other way around.

>
> 2.5.  Application Plane
>
>     Applications and services that use services from the control and/or
>     management plane form the Application Plane.
>
>     Addditionally, services residing in the Application Plane may provide
>     services to other services and applications that reside in the
>     application plane via the service interface.
>
>     Examples of applications include network topology discovery, network
>     provisioning, path reservation, etc.
>
>
>
>
>
> Haleplidis, et al.      Expires January 16, 2014                [Page 7]
>
> Internet-Draft   SDN Layers and Architecture Terminology       July 2013
>
>
> 3.  SDN Model View
>
>     We advocate that the SDN southbound interface should encompass both
>     the CSPI and the MSPI.
>
>     The SDN northbound interface is implemented in the Service
>     Abstraction Layer.
>
>     The above model can be used to describe in a concise manner all
>     prominent SDN-enabling technologies, as we explain in the following
>     subsections.

-- 
Salvatore Loreto, PhD
www.sloreto.com

---

From: [email-masked]
Date: Tue, 16 Jul 2013 11:32:35 -0700

hello,
included my comments in the word version of this document. did not find a
way to include comments for specific lines in plain text..

thanks,
sudhir

-- 
Sudhir Modali

---

From: "Haleplidis Evangelos" <[email-masked]>
Date: Wed, 17 Jul 2013 18:36:03 +0300

Greetings Salvatore,

Thank you very much for the comments.

> Service and Application, but we should also clarify and specify it much
> better.

Agreed. We will try to have something better in the next revision.

> Not all the REST API are supposed to be SDN North Bound interface and

Agreed. It was one example and of course not the only one. We intend to
include more in the next revision. 

Regards,
Evangelos Haleplidis.

---

From: "Haleplidis Evangelos" <[email-masked]>
Date: Wed, 17 Jul 2013 18:40:58 +0300

Thank you very much for your comments.

I also agree that there is a need to harmonize the terminology thus the
reason for this document.

Possibly this working group may be a good place to start, since we have
member from both the ONF and the OD.

Regarding your comments:

dmm> I would just note that there is no need for 2119 language

dmm> here as a protocol is not being specified.

EH> Thank you, we'll remove them at the next revision.

dmm> The term SAL is going to cause confusion as OpenDaylight

dmm> uses it in a different way; see
http://www.opendaylight.org/project/technical-overview

EH> As you suggested, we need such a discussion with people from all groups.

dmm> Might be worthwhile giving a few examples that not only show

dmm> the traditional devices (switches, routers, ...) but also

dmm> includes network appliances (physical and virtual)

EH> Agreed. We may need to explicitly open up the term "Network Device" to
incorporate, as you propose network appliances.

dmm> How about I2RS? BGP-LS? ...

EH> We intend to include more examples and describe in section 3, how
current and new frameworks are mapped into the Layered architecture.

dmm> This is confusing in that you're saying that both OF and

dmm> OF-Config both provide the DAL. Are they overlapping,

dmm> disjoint, ...?

The DAL encompasses both the forwarding and the operational planes of the
device and the DAL could be comprised of more than one abstraction models. 

OF covers only the DAL for the forwarding plane and cannot be used for the
operational plane from what I undertand, thus the need for OF-config.

>From my understanding, OF-config overlaps OF, but runs on a slower
time-scale than OF therefore making it useful for the Management plane
(similar to NETCONF).

dmm> What seems to be missing, among other things, is some sense

dmm> about what the state is actually used for (hence the

dmm> confusion of both OF and OF-Config providing [parts of] the

dmm> DAL), as well what kind of durability the state has (e.g.,

dmm> transactional, ephemeral, ...). Now, one might argue that

dmm> "state is state", but traditionally we haven't built

dmm> protocol stacks in this way (hence NETCONF and ISIS, ...).

I'm not certain I understand the comment. From my understanding, state is
something that applications, services and planes must keep and not something
that the abstraction layer has to keep. Although we may need to add such
text in the document to remove confusion.

Also, what else do you think we're missing?

Regards,

Evangelos Haleplidis.

From: Jamal Hadi Salim [mailto:[email-masked]] 
Sent: Tuesday, July 16, 2013 6:28 PM
To: David Meyer
Cc: Haleplidis Evangelos; [email-masked]; [email-masked]
Subject: Re: [Sdn] FW: New Version Notification for
draft-haleplidis-sdnrg-layer-terminology-00.txt

 

different semantics.

grained.

That

cheers,

jamal

---

From: "Haleplidis Evangelos" <[email-masked]>
Date: Wed, 17 Jul 2013 20:35:53 +0300

Greetings Sudhir,

Thank you very much for all your comments.

[1] Is this the scope of this document? The application layer is the core
driver for SDN, and is missing in the context here. Maybe a restructure of
this sentence is required to put the context in place.

No, that is not the scope of the document. But you may be right, we'll try
for a better intro and include the application layer in the intro text.

[2]Can we rather site 1 or 2 examples? As mentioned in the subsequent
sentence, this statement raises confusion rather than the obvious.

Ok. Will try to include a few examples in the next revision.

[3]General comment is that there are too many interfaces being proposed in
this document. I can already see this evolving into a complex architecture
like the IMS or other such. Is it possible to reduce/standardize on a couple
of interfaces between all layers to keep the architecture simple? This would
help in creating other paradigms that would allow for eg: a AP to talk
directly to DAL or something like AP->CP->MP->DAL without having to
translate between interfaces.

This document is not about trying to standardize, but rather to put things
in perspective and provide a common ground for terminology. However we'll
try to incorporate your suggestion in the next revision.

[4]It appears that ForCES and Openflow are being suggested as an option to
protocol/API/IPC. Isn't this wrong? ForCES and Openflow are control plane
services. I would imagine something like Restful API, OVF to be the
interface (CPSI).

ForCES and Openflow are not control plane services. CPSI's are for
configuration of the datapath and usually requires a high-throughput and low
latency Interface. ForCES and Openflow provide a way to separate the
forwarding from the control plane by providing such a protocol (Interface)
therefore a perfect fit for the CPSI. RESTful APIs usually based on HTTP are
not suitable for the CPSI, but they could be used for the MPSI. OVF has no
fit in CPSI. OVF describes software to run on virtual machines and not
related for the forwarding plane - how packets are handled.

Regards,

Evangelos Haleplidis.

From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, July 16, 2013 9:33 PM
To: Haleplidis Evangelos
Cc: [email-masked]
Subject: Re: [Sdn] FW: New Version Notification for
draft-haleplidis-sdnrg-layer-terminology-00.txt

hello,

thanks,
sudhir

On Tue, Jul 16, 2013 at 4:27 AM, Haleplidis Evangelos <[email-masked]>
wrote:

Greetings to all,

Regards,
Evangelos Haleplidis.

> Group:                 Individual Submission
http://www.ietf.org/internet-drafts/draft-haleplidis-sdnrg-layer-terminology
-00.txt

-- 
Sudhir Modali