Subject: [forces] FW: New Version Notification for draft-haleplidis-forces-packet-parallelization-03.txt

From: "Haleplidis Evangelos" <[email-masked]>
Date: Thu, 26 Sep 2013 23:40:45 +0300

Greetings to the list,
	
We just submitted an update for the packet parallelization draft.

There is one outstanding issue with this document and it regards nested parallel paths.

The issue has been raised by Dave Hood and arises with the merger, when multiple metadata arrive how would the merger distinguish which belong to the current parallel path and which for the outer parallel path.
There a number of ways to address the issue using the current defined Metadata Set (MS):

1.	One current MS and a table of MSs (tunneled metadata, namely a stack) followed by a depth index.
The merger will use only the current MS and get the top most from the MS stack and remove it and use it as current MS for the next round.
2.	Have a table with the current MS being the top most followed by a depth index.
3.	Add one additional field to the MS, namely a depth, and allow multiple MSs as structs that are being passed around and the merger uses only the highest number of depth and ignores the rest.
4.	Or we could simply not allow parallel paths.

We have discussed the issue and we were initially leaning towards the second option. However that would increase the complexity of the metadata that is passed around (a table with a structure per row).
Therefore we are currently leaning towards the fourth option opting for a simpler approach.

However we would like the opinion of the working group for resolving the issue.

Text in the document corresponding for nesting is prefixed by the words: “Edit. NPP:”

Regards,
Evangelos Haleplidis.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, September 26, 2013 11:33 PM
> To: Joel Halpern; Evangelos Haleplidis
> Subject: New Version Notification for draft-haleplidis-forces-packet-
> parallelization-03.txt
> 
> 
> A new version of I-D, draft-haleplidis-forces-packet-parallelization-
> 03.txt
> has been successfully submitted by Evangelos Haleplidis and posted to
> the IETF repository.
> 
> Filename:	 draft-haleplidis-forces-packet-parallelization
> Revision:	 03
> Title:		 ForCES Packet Parallelization
> Creation date:	 2013-09-26
> Group:		 Individual Submission
> Number of pages: 21
> URL:             http://www.ietf.org/internet-drafts/draft-haleplidis-forces-packet-parallelization-03.txt
> Status:          http://datatracker.ietf.org/doc/draft-haleplidis-forces-packet-parallelization
> Htmlized:        http://tools.ietf.org/html/draft-haleplidis-forces-packet-parallelization-03
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-haleplidis-forces-packet-parallelization-03
> 
> 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, 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.
> 
> 
> 
> 
> 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