ForCES Protocol Design Team update - 04/07/2004

The ForCES protocol team will be using the 
time line shown below for coming up with
the first draft of a ForCES protocol merger
proposal.

1.Before April 9th,
   a. A initial outline done
   b. decide whether and how we use XML and/or CVS
2.Before April 30th,
   a. Work out a final and detailed outline, and complete 
      discussion of major issues
   b. Distribute sections for individual writing
3. a. Complete writing of each sections - May' 20th
   b. Distribute sections for internal review - May'21st
   c. Incorporate sections and comments from protocol team - June 1st
4. Send to ForCES mailing list for external review - June 2nd
5. Submission to IETF - June 15th

This first draft made available to the ForCES list will
be on June 2nd.  In the interim, progress may be tracked
via the public archives and feedback may be given to the
the team via the URL below.

http://www.sstanamera.com/~forces/protocoldesignteam.html

-David

Revised LFB input/output text

After the dissemination of the last model draft in February
(draft-ietf-forces-model-02.txt), we got many very useful
comments.  Thanks.  One topic that generated lots of questions
was the concept of LFB inputs and outputs.  It became obvious
to us that in 02 we did not do a good job explaining the proposed
LFB input/output model.

Attached is a fully revised version of the relevant subsections
of 02 (3.2.1 and 3.2.2).  Hopefully this text conveys the design
intent much better.

Comments are welcome!

--
Zsolt Haraszti, Ph.D.                              Tel: +1 919 472 9949
Ericsson IP Infrastructure                         Fax: +1 919 472 9999
Raleigh NC USA                       Email: zsolt.haraszti <at> ericsson.com

3.2.1. LFB Outputs

A LFB output is a conceptual port on a LFB that can  send  information
to  some  other  LFB.  The  information  is  typically  a  packet  and
associated metadata, although in some cases it might consist  of  only
metadata, i.e., with no packet data.

A single LFB output can be connected to only one LFB  input.  This  is
required  to  make  the  packet  flow   through   the   LFB   topology
unambiguous.

Re: Revised LFB input/output text

Hi Zsolt.

This looks much better and makes sense to me now.

Minor nit: Should be ragged-right justification when
it is actually added to the model draft.

Cheers,
David

> -----Original Message-----
> From: Forwarding and Control Element Separation 
> [mailto:FORCES <at> PEACH.EASE.LSOFT.COM] On Behalf Of Zsolt Haraszti
> Sent: Wednesday, April 14, 2004 3:16 PM
> To: FORCES <at> PEACH.EASE.LSOFT.COM
> Subject: [FORCES] Revised LFB input/output text
> 
> After the dissemination of the last model draft in February
> (draft-ietf-forces-model-02.txt), we got many very useful
> comments.  Thanks.  One topic that generated lots of questions
> was the concept of LFB inputs and outputs.  It became obvious
> to us that in 02 we did not do a good job explaining the proposed
> LFB input/output model.
> 
> Attached is a fully revised version of the relevant subsections
> of 02 (3.2.1 and 3.2.2).  Hopefully this text conveys the design
> intent much better.
> 
> Comments are welcome!
> 

Re: Revised LFB input/output text

Hi, Jamal --

I promised that I will get back to you on the confusion over input/output group concept. If you have not done
so, I would encourage you read over the new text Zsotl sent out. I hope that address the issues for you. If
not, please let us know.

Thanks for your earlier comments. That really help the model team to dig deeper into the subject and come up
with this new (and better, in my opinion) text. 

Lily

> -----Original Message-----
> From: Forwarding and Control Element Separation
> [mailto:FORCES <at> PEACH.EASE.LSOFT.COM]On Behalf Of Putzolu, David
> Sent: Tuesday, April 20, 2004 3:54 PM
> To: FORCES <at> PEACH.EASE.LSOFT.COM
> Subject: Re: Revised LFB input/output text
> 
> 
> Hi Zsolt.
> 
> This looks much better and makes sense to me now.
> 
> Minor nit: Should be ragged-right justification when
> it is actually added to the model draft.
> 
> Cheers,
> David
>  
> 

Re: Revised LFB input/output text

Zsolt,

Finally getting around to reviewing this text.  It is much improved!!!
Thanks.

Just a clarification.  The concept of a group is really used to allow
certain variance in the *instantiations* of a particular LFB class.  An
instantiation of a particular LFB class may (or may not) only set
certain upper and lower bounds on the number of ports contained in a
group, via it's attributes.  The group concept does not allow an
instantiation of a class to dynamically grow/shrink the number of ports
in an output group beyond what can be specified by it's attributes.  Is
this a correct understanding?

Along the same lines, there is a sentence in the text that states:

"The number  of  actual input instances in the group is an attribute of
the LFB  class, which is  read-only  for  static  topologies,  and  it
is  read-write for configurable topologies."

Shouldn't that say the input instances in the group are an attribute of
an *instance* of an LFB class?

Regards,

Gamil.

Gamil Cain
Software Architect
Intel Research & Development

Re: Revised LFB input/output text

See below for my own understanding. I am sure Zsolt will correct me if I get it wrong.

> -----Original Message-----
> From: Forwarding and Control Element Separation
> [mailto:FORCES <at> PEACH.EASE.LSOFT.COM]On Behalf Of Cain, Gamil
> Sent: Thursday, April 22, 2004 9:16 AM
> To: FORCES <at> PEACH.EASE.LSOFT.COM
> Subject: Re: Revised LFB input/output text
> 
> 
> Zsolt,
> 
> Finally getting around to reviewing this text.  It is much improved!!!
> Thanks.
> 
> Just a clarification.  The concept of a group is really used to allow
> certain variance in the *instantiations* of a particular LFB 
> class.  An
> instantiation of a particular LFB class may (or may not) only set
> certain upper and lower bounds on the number of ports contained in a
> group, via it's attributes.  The group concept does not allow an
> instantiation of a class to dynamically grow/shrink the 
> number of ports
> in an output group beyond what can be specified by it's 
> attributes.  Is
> this a correct understanding?
YES.
> 
> Along the same lines, there is a sentence in the text that states:
> 

Re: Revised LFB input/output text

Lily, Zsolt,

On Tue, 2004-04-20 at 19:16, Yang, Lily L wrote:
> Hi, Jamal --
>
> I promised that I will get back to you on the confusion over
> input/output group concept. If you have not done so, I would
> encourage you read over the new text Zsotl sent out. I hope
> that address the issues for you. If not, please let us know.
>

Where is the text on the metadata? ;->
I finaly got to reading this. To be honest, i wouldnt say i am thrilled
although i would say there is an improvement. As an example, the input
grouping(section 3.2.2. LFB Inputs) with the three alternatives offered
is a good approach because it doesnt lean on one thing only and rather
points the alternative. The danger with model drafts is that people
with weak minds (who may take the shape of customers) will end up taking
them literally in 3 years after publication.
Iam trying hard to make it fit my mental view of things. Maybe i should
explain my view of the world then lets see if theres a middle ground
view which doesnt leave it out.
So in my world (as the expedia commercial starts) there are no input or
output groups.
Let me throw in a diagram to clarify.

      +--------------+       +------------------+
      | LFB X        +---+   |                  |      +--------------+
      +--------------+   |   |                  |  +-->| LFB A        |
                         |   |                  |  |   +--------------+

Change to ForCES List Moderation Policy

All,

Due to the high volume of non-subscriber spam, the
ForCES list configuration is being changed as follows.

- Previously non-subscriber mail was reviewed by the
  chairs and forwarded if appropriate
+ Going forward, non-subscriber mail will be automatically
  rejected. Non-subscribers must contact me or Patrick 
  (dro <at> zurich.ibm.com) directly to have their email 
  forwarded to the list.

Handling of subscriber posts remains unchanged, that is,
all subscriber posts are verified via a nonce to the
sender, then posted to the list.

The ForCES mailing list moderation policy is fully
explained at:
http://www.sstanamera.com/~forces/mailing.html

-David

Re: Revised LFB input/output text

Jamal --
The key difference I see in your view and the view described in the model document is regarding the output
branching -- everything else you said seem in sync with the model we have in mind.
In your description:
> 5) There may be multiple output paths from an LFB
> 6) Processing results which may consult state decide on the output
> edge/branch to take.
> 7) metadata may be encoded as a result of #6 above in order to
> influence nexthop LFB processing (as described in #4 above)
I understand that the branching is driven by the "metadata". But we need to explicitly model that behavior
somewhere in this graph. 
And the picture you drew shows that one output from LFB can branch into several different LFB for next step of
processing. It is not clear to me where/how the "metadata driven branching" is modeled. 
That kind of branching is prohibited explicitly in our current model with a good reason:
"A single LFB output can be connected to only one LFB  input.  This  is
required  to  make  the  packet  flow   through   the   LFB   topology
unambiguous."

A simple way to model that behavior would be inserting a "redirector" LFB between the output branch and the
multiple next step LFBs. The "redirector" LFB has one input and multiple output, and the only processing
it does is to send packets to different output according to the metadata. 

So all in all, what you want is indeed provided by the current model -- as long as you explictly model them.

Another thing you said which I don't quite agree is that you don't see any difference in example a) and b). If
the LFB to be modeled tend to process the packets and sort them into two different categories -- then we
should model them explicitly within the LFB and the multiple outputs enable just that -- the semantic
difference between the two outputs.

Granted, just because we provide all these mechanisms/alternatives, it doesn't mean every LFB designer

Re: Revised LFB input/output text

On Tue, 2004-04-27 at 18:40, Yang, Lily L wrote:
> Jamal --
> The key difference I see in your view and the view described in the model
> document is regarding the output branching -- everything else you said seem
> in sync with the model we have in mind.

The input has several choices of which what i have in minds fits in one
of three posibilities.
So that part is fine.

> In your description:
> > 5) There may be multiple output paths from an LFB
> > 6) Processing results which may consult state decide on the output
> > edge/branch to take.
> > 7) metadata may be encoded as a result of #6 above in order to
> > influence nexthop LFB processing (as described in #4 above)

> I understand that the branching is driven by the "metadata".

There are several "branchings"
a) to the "processing" within an LFB
b) to the output post processing.

#a maybe be influenced by metadata and existing state.
Seems like you refer to #b which is not driven by metadata.

>  But we need
> to explicitly model that behavior somewhere in this graph.
> And the picture you drew shows that one output from LFB can branch into
> several different LFB for next step of processing. It is not clear to me