Subject: [Sdn] My review of draft-irtf-sdnrg-layer-terminology-00

From: Spencer Dawkins <[email-masked]>
Date: Fri, 12 Sep 2014 15:02:42 -0500

Hi,

David Meyer asked me to do a review of 
draft-irtf-sdnrg-layer-terminology-00. Thanks for the opportunity to do 
that.

My impression of this document is very positive. I found reading it to 
be helpful professionally (in my day job).

Spencer

--

I have some notes you might want to consider, and most fall into the 
category of "minor issues and nits".

I did have one observation that might involve some surgery. This 
document is billed as "terminology", which is fine, and sections 3 and 4 
go beyond terminology, which is probably fine, but there are small 
chunks of requirements, such as

    o  CAL and MAL must be able to utilize the ForCES protocol.
    o  CAL must be able to utilize the OpenFlow protocol.
    o  MAL must be able to utilize the NETCONF protocol.

Do these belong in a "terminology" document? If they do, is sticking 
requirements that affect CAL and MAL in the sections that describe 
mappings to various protocols the right place to put them?

In this text:

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 their associated 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 addresses these questions and provides a concise reference
    for SDNRG and the wider SDN community based on relevant peer-reviewed
        ^^^^^
in an IETF-stream document, we typically wouldn't refer to working group 
names, because working groups conclude. IRTF RGs have longer lives, so 
maybe this is OK in an IRTF-stream document, but if you don't replace 
this with something like "the SDN research community", you should 
probably expand SDNRG, as you do in the following paragraph.

There are about 10 or so occurrences, including references to current 
charter items and discussions at various IETF meetings.

    literature, the RFC series, and relevant documents by other standards
    organizations.

    This document is a product of the IRTF Software-Defined Networking
    Research Group (SDNRG)

In this text:

    The first version of this document was published in July 2013.
    Subsequently, updated versions were presented during the SDNRG
    meetings at IETF 88, IETF 89, and IETF 90 and have been reviewed,
    commented, and discussed extensively for more than one year by the
    vast majority of SDNRG members, which certainly exceeds 100
    individuals.  It is the consensus of SDNRG that this document should
    be published in the IRTF Stream RFC Series [RFC5743].

I usually see material like this in shepherd writeups (where it's 
valuable during the approval process). I'm not sure it's valuable in a 
forever RFC.

In this text:

3.2.  Network Devices

    A Network Device is an entity that receives packets on its ports and
                                                ^^^^^^^
    performs one or more network functions on them.  For example, the
    network device could forward a received packet, drop it, alter the
    packet header (or payload) and forward the packet, and so on.  A
    Network Device is an aggregation of multiple resources such as ports,
    CPU, memory and queues.  Resources are either simple or can be
    aggregated to form complex resources that can be viewed as one
    resource.  The Network Device is in itself a complex resource.
    Examples of Network Devices include switches and routers.  Additional
    examples include network elements that may operate at a layer above
    IP, such as firewalls, load balancers and video transcoders or even
    Layer 1 devices such as optical or microwave network elements.
    ^^^^^ ^ ^^^^^^^

Are these statements consistent? The first describes packet 
functionality, the second describes what happens at the physical layer. 
Note that I think including non-packet functionality is fine - the 
definition should be consistent. The data plane packet emphasis happens 
in multiple places in the document.

In this text:

    o  Technically, the YANG model [RFC6020] can be used to specify DAL
       ^^^^^^^^^^^
       for the Forwarding plane as well.  That said, in principle,
                                                     ^^ ^^^^^^^^^
       NETCONF [RFC6241] is a management protocol which was not
       (originally) designed for fast CP updates, and it might not be
       suitable for addressing the requirements of CPSI.

I don't think either of these phrases is necessary. The first is 
actually confusing (I don't understand what "technically" means in this 
context), the second is harmless, but the paragraph is clear if you 
remove both.

In this text:

4.3.  OpenFlow

    [OpenFlow] is a framework originally developed by Stanford,
                                                   ^^ ^^^^^^^^
This would be clearer if it was

    [OpenFlow] is a framework originally developed at Stanford University,
                                                   ^^ ^^^^^^^^ ^^^^^^^^^^
Someday, people consulting this reference won't remember where OpenFlow 
came from, but at the very least, "by" should be "at".

In this text:

    OpenFlow has undergone many revisions.  The current version is 1.4
    [OpenFlow] and supports amongst others, multiple controllers for high
    availability and extensible flow match field protocol messages to
    support arbitrary match fields.  Efforts to define OpenFlow 2.0
    [PPIPP] are already underway aiming to provide an abstract forwarding
    model to provide protocol independence and device programmability.

most of this won't be helpful in a few years. The helpful parts would be 
something like

    OpenFlow has undergone many revisions, and additional revisions are
    likely.  The following description reflects OpenFlow version 1.4.

In this text:

4.4.  I2RS
       ^^^^
This is the first occurrence in the body of the document. You might 
helpfully expand it as "Interface to the Routing System"

    I2RS is currently developed by a recently-established IETF working
         ^^ ^^^^^^^^^ ^^^^^^^^^ ^^ ^ ^^^^^^^^^^^^^^^^^^^^ ^^^^ ^^^^^^^
    group.  The intention is to provide a standard interface to the
    ^^^^^^  ^^^ ^^^^^^^^^ ^^ ^^ ^^^^^^^
    routing system for real-time or event-driven interaction through a
    collection of protocol-based control or management interfaces.
    Essentially, I2RS aims to make the routing information base (RIB)
    programmable thus enabling new kinds of network provisioning and
    operation.

The first part of this paragraph won't age well, in five years. I'd 
suggest replacing it with "I2RS provides".

It's a nit, but in this text:

4.6.  PCEP

    The Path Computation Element (PCE) [RFC4655] architecture describes
    the PCE, an entity capable of computing paths for a single or set of
    services.  A PCE might be a network node, network management station,
    or dedicated computational platform that is resource-aware and has
    the ability to consider multiple constraints for a variety of path
    computation problems and switching technologies.  The PCE
    Communication Protocol (PCEP) (PCEP) [RFC5440] is an IETF protocol
                           ^^^^^^ ^^^^^^
    for communication between a Path Computation Client (PCC) and a PCE,
    or between multiple PCEs.

I think that's duplicated.

---

From: David Meyer <[email-masked]>
Date: Fri, 12 Sep 2014 13:04:55 -0700

Thank you for your detailed comments and review. Much appreciated!

--dmm

On Fri, Sep 12, 2014 at 1:02 PM, Spencer Dawkins <
[email-masked]> wrote:

> Hi,
>
> David Meyer asked me to do a review of draft-irtf-sdnrg-layer-terminology-00.
> Thanks for the opportunity to do that.
>
> My impression of this document is very positive. I found reading it to be
> helpful professionally (in my day job).
>
> Spencer
>
> --
>
> I did have one observation that might involve some surgery. This document
> is billed as "terminology", which is fine, and sections 3 and 4 go beyond
> terminology, which is probably fine, but there are small chunks of
> requirements, such as
>
> requirements that affect CAL and MAL in the sections that describe mappings
> to various protocols the right place to put them?
>
> In this text:
>
> Abstract
>
> maybe this is OK in an IRTF-stream document, but if you don't replace this
> with something like "the SDN research community", you should probably
> expand SDNRG, as you do in the following paragraph.
>
> I usually see material like this in shepherd writeups (where it's valuable
> during the approval process). I'm not sure it's valuable in a forever RFC.
>
> In this text:
>
> 3.2.  Network Devices
>
> Are these statements consistent? The first describes packet functionality,
> the second describes what happens at the physical layer. Note that I think
> including non-packet functionality is fine - the definition should be
> consistent. The data plane packet emphasis happens in multiple places in
> the document.
>
> In this text:
>
> I don't think either of these phrases is necessary. The first is actually
> confusing (I don't understand what "technically" means in this context),
> the second is harmless, but the paragraph is clear if you remove both.
>
> In this text:
>
> 4.3.  OpenFlow
>
> _______________________________________________
> sdn mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/sdn
>