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

From: "Haleplidis Evangelos" <[email-masked]>
Date: Wed, 23 Jul 2014 09:50:08 -0400

Greetings to the list,

Apologies for the late posting.
We have submitted a new draft based on the comments and suggestions of the IETF 89 and the mailing list.

Regards,
Evangelos Haleplidis.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, July 23, 2014 9:17 AM
> To: Evangelos Haleplidis; Spyros Denazis; Odysseas Koufopavlou; David
> Meyer; Kostas Pentikousis; Jamal Hadi Salim; David Meyer; Jamal Hadi
> Salim; Evangelos Haleplidis; Spyros Denazis; Kostas Pentikousis;
> Odysseas Koufopavlou
> Subject: New Version Notification for draft-haleplidis-sdnrg-layer-
> terminology-06.txt
> 
> 
> A new version of I-D, draft-haleplidis-sdnrg-layer-terminology-06.txt
> has been successfully submitted by Evangelos Haleplidis and posted to
> the IETF repository.
> 
> Name:		draft-haleplidis-sdnrg-layer-terminology
> Revision:	06
> Title:		SDN Layers and Architecture Terminology
> Document date:	2014-07-22
> Group:		Individual Submission
> Pages:		31
> URL:            http://www.ietf.org/internet-drafts/draft-haleplidis-sdnrg-layer-terminology-06.txt
> Status:         https://datatracker.ietf.org/doc/draft-haleplidis-sdnrg-layer-terminology/
> Htmlized:       http://tools.ietf.org/html/draft-haleplidis-sdnrg-layer-terminology-06
> Diff:           http://www.ietf.org/rfcdiff?url2=draft-haleplidis-sdnrg-layer-terminology-06
> 
> Abstract:
>    Software-Defined Networking (SDN) can be defined as a new approach
>    for network programmability.  Network programmability in this
> context
>    refers to the capacity to initialize, control, change, and manage
>    network behavior dynamically via open interfaces as opposed to
>    relying on closed-box solutions and proprietary interfaces.  SDN
>    emphasizes the role of software in running networks through the
>    introduction of an abstraction for the data forwarding plane and, by
>    doing so, separates it from the control plane.  This separation
>    allows faster innovation cycles at both planes as experience has
>    already shown.  However, there is increasing confusion as to what
>    exactly SDN is, what is the layer structure in an SDN architecture
>    and how do layers interface with each other.  This document aims to
>    answer these questions and provide a concise reference document for
>    SDNRG, in particular, and the SDN community, in general, based on
>    relevant peer-reviewed literature and documents in the RFC series.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
> 
> The IETF Secretariat

---

From: Dimitri Staessens <[email-masked]>
Date: Mon, 28 Jul 2014 17:06:37 +0200

Dear all,

At IETF90 I was at sdnrg and noticed mentionof RINA in the presentation 
given by Evangelos concerning this draft. I'm happy to see that RINA is 
getting some attention from the IRTF community in general and the sdnrg 
in particular.

I've been working on the RINA topic for the better part of the past 2 
years in a number of EC-funded (FP7) projects, IRATI and PRISTINE, and 
am technical lead for a smaller project within Geant3+ (called IRINA) 
focusing on RINA. I'm not entirely sure it's all that relevant to the 
group, but I'd like to comment/clarify a little bit on the RINA 
paragraph (Section 3, page 6).

First two small non-RINA-related comments on the current draft:
1) Definition of Network Device (Section 2, p.5): should the definition 
also include monitoring in addition to manipulation and forwarding?
2) BFD (Section 4.7, p.23): "...physical media that do not support 
failure detection of any kind, such as Ethernet,..." "Ethernet" should 
be carefully defined here, as IEEE 802.3 Autonegotiation and IEEE 
802.1ag do support failure detection of some kind.

For the RINA part:
In a (tiny) nutshell, RINA extends the concept of Inter-Process 
Communication (IPC) to distributed systems and applications. To be more 
precise: communication endpoints are Application Processes (or even more 
precise, the communication tasks within these Applications, named 
Application Entities) that communicate using IPC services (via the IPC 
API). If the Application Processes are on different systems, they use 
another distributed application (called a Distributed IPC facility), 
which is a (homogenous) distributed application consisting of (only) IPC 
processes, exposing the IPC API northbound and using the IPC southbound. 
The IPC API has 3 functions (read/write, register/unregister, 
allocate_flow/deallocate_flow) and can pass a set of parameters to 
request certain service characteristics. This DIF corresponds to a 
"network layer". This recurses until we reach the physical layer, where 
special IPC processes (called Shim IPC processes) are tailored to the 
transmission hardware. These shim IPC processes only expose the IPC API 
northbound.

There have been proposals for a recursive SDN control plane, e.g. within 
the FP7 SPARC (SplitArchitecture) project, where controllers expose 
Openflow both as a northbound and southbound API, but this is not really 
reflected in Figure 1. Even there, I think the commonalities are mostly 
superficial (i.e. there being some form of recursion by having the same 
API northbound and southbound).

I'd be happy to discuss if there are commonalities between RINA and the 
proposed SDN architecture, and contribute to this part of the draft.

cheers,

Dimitri

Haleplidis Evangelos schreef op 7/23/2014 3:50 PM:
> _______________________________________________
> sdn mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/sdn

-- 
Dimitri Staessens
Department of Information Technology
Broadband Communication Networks (IBCN)
Ghent University - iMinds
Gaston Crommenlaan 8 (Bus 201), B-9050 Gent, Belgium
T: +32 472 18 72 48; T Secr: +32 9 33 14900
F: +32 9 33 14899
Skype: dstaesse
E: [email-masked]
W : www.ibcn.intec.UGent.be // www.iminds.be