Forwarding and Control Element Separation (ForCES) Packet Parallelization
draft-ietf-forces-packet-parallelization-03

[Ballot comment]
Just being pedantic, but I find it disconcerting to use "cilc" when it is easier and clearer to call it by its given name "cilk".

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-forces-packet-parallelization-02.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA understands that, upon approval of this document, there are two actions which IANA must complete.

First, in the Logical Functional Block (LFB) Class Names and Class Identifiers registry in the Forwarding and Control Element Separation (ForCES) page at

https://www.iana.org/assignments/forces/

three new registrations are to be made in the range administered through the First Come First Served policy defined by RFC 5226.  These new registrations are as follows:

LFB Class Identifier: 65537 (if available)
LFB Class Name: Ext-Splitter
LFB Version: 1.0
Description: A splitter LFB will either send the same packet or chunks of one packet to multiple LFBs.
Reference: [ RFC-to-be ]

LFB Class Identifier: 65538 (if available)
LFB Class Name: Ext-Merger
LFB Version: 1.0
Description: A merger LFB receives multiple packets or multiple chunks of the same packet and merges them into one.
Reference: [ RFC-to-be ]

LFB Class Identifier: 65539 (if available)
LFB Class Name: Ext-CoreParallelization
LFB Version: 1.0
Description: A core LFB to signify the parallelization capability
Reference: [ RFC-to-be ]

NOTE: In the Ext-Merger description in section 7.1, s/merge/merges


Second, in the Metadata ID namespace, also in the Forwarding and Control Element Separation (ForCES) page at

https://www.iana.org/assignments/forces/

a new Metadata ID is to be registered as follows:

Value: [ TBD-at-registration ]
Name: ParallelMetadataSet
Reference: [ RFC-to-be ]

IANA notes that the authors suggest a value of 0x00000010 for this value.  In addition, IANA notes that the designated expert for this registry has approved this registration.

IANA understands that these are the only actions required upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 

Please note that IANA cannot reserve specific values. If the authors believe that these values could be registered by another party or document before the IESG approves this one, because these are First Come First Served and Specification Required registries, they can submit registration requests directly to IANA at any time.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (ForCES Packet Parallelization) to Proposed Standard


The IESG has received a request from the Forwarding and Control Element
Separation WG (forces) to consider the following document:
- 'ForCES Packet Parallelization'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-09-29. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

  Forwarding and Control Element Separation (ForCES) defines an
  architectural framework and associated protocols to standardize
  information exchange between the control plane and the forwarding
  plane in a ForCES Network Element (ForCES NE).  RFC5812 has defined
  the ForCES Model provides a formal way to represent the capabilities,
  state, and configuration of forwarding elements within the context of
  the ForCES protocol (RFC 5810), so that control elements (CEs) can
  control the FEs accordingly.  More specifically, the model describes
  the logical functions that are present in an FE, what capabilities
  these functions support, and how these functions are or can be
  interconnected.

  Many network devices support parallel packet processing.  This
  document describes how ForCES can model a network device's
  parallelization datapath.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-forces-packet-parallelization/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-forces-packet-parallelization/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/2329/

1. Summary

The document shepherd is Damascene Joachimpillai
The responsible Area Director is Adrian Farrel

This document describes how packet parallelization, a feature present in many
networking devices, is supported by the ForCES model. This document defines two
new LFBs that provide support for parallelization and a new core LFB to notify the
FE's capability to parallelize packet processing.

2. Review and Consensus

The document has had a number of iterations based on comments and discussions
both in meetings and the mailing list. The LFB definitions and descriptions have been
reviewed and are straightforward.
At least one implementation has validated some of the features described in the
document. 
We believe the working group is solidly behind this document.

3. Intellectual Property

The author has confirmed conformance with BCP 78/79.
There is only one known IPR disclosure on the document.

4. Other Points

a. Figure 1 shows packets in the split while the authors define them as chunks.
Suggest to change the "P" to "C1, C2 ... CN" in the figure to be accurate.

b. Running idnits suggests that there is a normative reference to RFC5810 but there is
no explicit reference in the document.

c. Use spell checker tool. There are a few spell errors, e.g. s/tasls/tasks

AD review
=======

Hi authors,

I have done my usual AD review on receiving a publication request for
your draft.

I have a question, a request, and a suggestion.

I'll put the document into "Revised I-D" state until we have resolved
these issues.

Thanks for the work,
Adrian

---

Is this really standards track and not experimental? The reason I ask is
because it sounds (to me) that packet parallelization is quite an
advanced feature that may have some "interesting" behavioral
characteristics. If you tell me that, "this is stable, we know what we
are doing, the implementations that exist are really being deployed"
then I'll be happy. If you say "we have an implementation and are seeing
how it behaves" then perhaps you should consider whether this is an
experiment.

This is a topic for discussion. You don't have to make a change until we
have covered the ground and understand what we are dealing with.

---

The IANA Considerations section needs some work. Please:
- Name the registries where you are requesting code points.
- Please request allocations (i.e. don't write descriptive text)
- the values you are asking for appear to come from the Standards
  Action space: why mention FCFS?
- Do you *need* the values you are asking for (18-20 and x10), are you
  suggesting them, or do you not actually care? You need to make this
  clear in your text.

---

Some comments from the document shepherd are recorded in the write-up and should get some attention from the authors.

Additionally, there is some English that could benefit from a quick re-read and some polish.

1. Summary

The document shepherd is Damascene Joachimpillai
The responsible Area Director is Adrian Farrel

This document describes how packet parallelization, a feature present in many
networking devices, is supported by the ForCES model. This document defines two new
LFBs that provide support for parallelization and a new core LFB to notify the
FE's capability to parallelize packet processing.

2. Review and Consensus

The document has had a number of iterations based on comments and discussions both in
meetings and the mailing list. The LFB definitions and descriptions have been reviewed and are straightforward.
At least one implementation has validated some of the features described in the document. 
We believe the working group is solidly behind this document.

3. Intellectual Property

The author has confirmed conformance with BCP 78/79.
There is only one known IPR disclosure on the document.

4. Other Points

a. Figure 1 shows packets in the split while the authors define them as chunks. Suggest to change the "P" to "C1, C2 ... CN" in the figure to be accurate.

b. Running idnits suggests that there is a normative reference to RFC5810 but there is no explicit reference in the document.

c. Use spell checker tool. There are a few spell errors, e.g. s/tasls/tasks